On Wed, May 06, 2015 at 03:55:20PM +0200, Michal Hocko wrote: > On Wed 06-05-15 16:25:10, Vladimir Davydov wrote: > > On Wed, May 06, 2015 at 02:35:41PM +0200, Michal Hocko wrote: [...] > > > NOACCOUNT doesn't imply kmem at all so it is not clear who is in charge > > > of the accounting. > > > > IMO it is a benefit. If one day for some reason we want to bypass memcg > > accounting for some other type of allocation somewhere, we can simply > > reuse it. > > But what if somebody, say a highlevel memory allocator in the kernel, > want's to (ab)use this flag for its internal purpose as well? We won't let him :-) If we take your argument about future (ab)users seriously, we should also consider what will happen if one wants to use e.g. __GFP_HARDWALL, which BTW has a generic name too although it's cpuset-specific. My point is that MEMCG is the only subsystem of the kernel that tries to do full memory accounting, and there is no point in introducing another one, because we already have it. So we have full right to reserve __GFP_NOACCOUNT for our purposes, just like cpuset reserves __GFP_HARDWALL and kmemcheck __GFP_NOTRACK. Any newcomer must take this into account. Thanks, Vladimir -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>