Re: [PATCH 1/2] gfp: add __GFP_NOACCOUNT

[Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>]

On Wed 06-05-15 09:16:22, Johannes Weiner wrote:
> On Wed, May 06, 2015 at 01:59:41PM +0200, Michal Hocko wrote:
> > On Tue 05-05-15 12:45:42, Vladimir Davydov wrote:
> > > Not all kmem allocations should be accounted to memcg. The following
> > > patch gives an example when accounting of a certain type of allocations
> > > to memcg can effectively result in a memory leak.
> > 
> > > This patch adds the __GFP_NOACCOUNT flag which if passed to kmalloc
> > > and friends will force the allocation to go through the root
> > > cgroup. It will be used by the next patch.
> > 
> > The name of the flag is way too generic. It is not clear that the
> > accounting is KMEMCG related.
> 
> The memory controller is the (primary) component that accounts
> physical memory allocations in the kernel, so I don't see how this
> would be ambiguous in any way.

What if a high-level allocator wants to do some accounting as well?
E.g. slab allocator accounts {un}reclaimable pages. It is a different
thing because the accounting is per-cache rather than gfp based but I
just wanted to point out that accounting is rather a wide term.

> > __GFP_NO_KMEMCG sounds better?
> 
> I think that's much worse.  I would prefer communicating the desired
> behavior directly instead of having to derive it from a subsystem
> name.
> (And KMEMCG should not even be a term, it's all just the memory
> controller, i.e. memcg.)

I do not mind __GFP_NO_MEMCG either.

-- 
Michal Hocko
SUSE Labs