Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp5375348imm; Tue, 19 Jun 2018 09:24:27 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJM0+hKHcPt58c7eCqufUm5/A7JXxU9fhsPtkGmcVXMZlIoMaK4VEsgH35uRATLd5fgMhJ7 X-Received: by 2002:a62:5991:: with SMTP id k17-v6mr18809059pfj.94.1529425467421; Tue, 19 Jun 2018 09:24:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529425467; cv=none; d=google.com; s=arc-20160816; b=lcyujfHwb0DN/2DfBPNHczuPf8qZmVtmvr2A7mPHRq3m4G+HkRYPg7DxBzLBQVwcXX FCySEHKoI5d6PZskFQhfWqrE7Db2yb1XwNtpCMZ9UWOh1qOOhR6b8PbwzJNcPoUJPOrR Johx32teRGALQPZuTK0Z0C27QbRFs4iiIQe27h+Hf0CSTPGDGUHWB3Crzt4lrbux7+Wi UVTRdlpFRMpe24/74TP0IwpfwJb08BxwHh8S17KI2gc4ZGE7W/USXZgw0CfCFAEmLv33 n8qWNoz0rQMudMkDLMOzW2PSOUaCtu2oyKoFxx6fuaAzk03C4klu7rH4bYKYDY/lbfTV EEKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=TSneSij/NwWRu9WgHJ0ki+talneVpfYwESX9cv3GXak=; b=ihIW3XRAxv/wSr6n/rV+2c9jQqwzSnDlIOZMRPQulu/ZEz8ZCOFEUGeGz6/j07GyhD GHN4aE/a8IjEN03N/O7VXcel++fNPL00mxqhRJ61BPUf6ewah+DYrzlbcVRbxAQF+q6S TdICWwmy/90pKJ+FGEx5jfMoanQJu44zY/6EMnnUb8JkUopzPfOy8j2b0qJ7J4YE3VPw lVftiu7rcnnQKorapbbDF0l0hQVlR7wBeC9Tn1/DYU8vreZsV0nBhfCkNFxvOjqsXTzN 5tSabB7YcHRuWQiFQTsOzZ794ZMhz151Ihn9SAk9RQjwaWyC9KPN6gANAKzubOVZEN+6 hFMw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@cmpxchg.org header.s=x header.b=T5JT+mkM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=cmpxchg.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v26-v6si24979pgc.416.2018.06.19.09.24.13; Tue, 19 Jun 2018 09:24:27 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@cmpxchg.org header.s=x header.b=T5JT+mkM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=cmpxchg.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966999AbeFSQWP (ORCPT + 99 others); Tue, 19 Jun 2018 12:22:15 -0400 Received: from gum.cmpxchg.org ([85.214.110.215]:48436 "EHLO gum.cmpxchg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966650AbeFSQWN (ORCPT ); Tue, 19 Jun 2018 12:22:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cmpxchg.org ; s=x; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject: Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=TSneSij/NwWRu9WgHJ0ki+talneVpfYwESX9cv3GXak=; b=T5JT+mkMxFT7mNf/otyJHXrIDR QjTyTLjeM8fEhTWm0iNfTtWsi8nD2QgbIqPN06Io0zuLFQHJx7f1ocAKVuCfFdPz4WmBGbS9AHWds Kk3CH7jS0naGBE8S+t51WcxHXujOXTdH4ACuLpZIOLlSvQNP+Wc6m1VqUg4V2yArN8c8=; Date: Tue, 19 Jun 2018 12:24:29 -0400 From: Johannes Weiner To: Shakeel Butt Cc: Andrew Morton , Michal Hocko , Vladimir Davydov , Jan Kara , Greg Thelen , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Jan Kara , Amir Goldstein , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Mel Gorman , Vlastimil Babka , Alexander Viro Subject: Re: [PATCH 1/3] mm: memcg: remote memcg charging for kmem allocations Message-ID: <20180619162429.GB27423@cmpxchg.org> References: <20180619051327.149716-1-shakeelb@google.com> <20180619051327.149716-2-shakeelb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180619051327.149716-2-shakeelb@google.com> User-Agent: Mutt/1.10.0 (2018-05-17) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 18, 2018 at 10:13:25PM -0700, Shakeel Butt wrote: > @@ -248,6 +248,30 @@ static inline void memalloc_noreclaim_restore(unsigned int flags) > current->flags = (current->flags & ~PF_MEMALLOC) | flags; > } > > +#ifdef CONFIG_MEMCG > +static inline struct mem_cgroup *memalloc_memcg_save(struct mem_cgroup *memcg) > +{ > + struct mem_cgroup *old_memcg = current->target_memcg; > + > + current->target_memcg = memcg; > + return old_memcg; > +} > + > +static inline void memalloc_memcg_restore(struct mem_cgroup *memcg) > +{ > + current->target_memcg = memcg; > +} The use_mm() and friends naming scheme would be better here: memalloc_use_memcg(), memalloc_unuse_memcg(), current->active_memcg > @@ -375,6 +376,27 @@ static __always_inline void kfree_bulk(size_t size, void **p) > kmem_cache_free_bulk(NULL, size, p); > } > > +/* > + * Calling kmem_cache_alloc_memcg implicitly assumes that the caller wants > + * a __GFP_ACCOUNT allocation. However if memcg is NULL then > + * kmem_cache_alloc_memcg is same as kmem_cache_alloc. > + */ > +static __always_inline void *kmem_cache_alloc_memcg(struct kmem_cache *cachep, > + gfp_t flags, > + struct mem_cgroup *memcg) > +{ > + struct mem_cgroup *old_memcg; > + void *ptr; > + > + if (!memcg) > + return kmem_cache_alloc(cachep, flags); > + > + old_memcg = memalloc_memcg_save(memcg); > + ptr = kmem_cache_alloc(cachep, flags | __GFP_ACCOUNT); > + memalloc_memcg_restore(old_memcg); > + return ptr; I'm not a big fan of these functions as an interface because it implies that kmem_cache_alloc() et al wouldn't charge a memcg - but they do, just using current's memcg. It's also a lot of churn to duplicate all the various slab functions. Can you please inline the save/restore (or use/unuse) functions into the callsites? If you make them handle NULL as parameters, it merely adds two bracketing lines around the allocation call in the callsites, which I think would be better to understand - in particular with a comment on why we are charging *that* group instead of current's. > +static __always_inline struct mem_cgroup *get_mem_cgroup( > + struct mem_cgroup *memcg, struct mm_struct *mm) > +{ > + if (unlikely(memcg)) { > + rcu_read_lock(); > + if (css_tryget_online(&memcg->css)) { > + rcu_read_unlock(); > + return memcg; > + } > + rcu_read_unlock(); > + } > + return get_mem_cgroup_from_mm(mm); > +} > + > /** > * mem_cgroup_iter - iterate over memory cgroup hierarchy > * @root: hierarchy root > @@ -2260,7 +2274,7 @@ struct kmem_cache *memcg_kmem_get_cache(struct kmem_cache *cachep) > if (current->memcg_kmem_skip_account) > return cachep; > > - memcg = get_mem_cgroup_from_mm(current->mm); > + memcg = get_mem_cgroup(current->target_memcg, current->mm); get_mem_cgroup_from_current(), which uses current->active_memcg if set and current->mm->memcg otherwise, would be a nicer abstraction IMO.