On Wed, Aug 15, 2018 at 03:25:11PM -0700, Andrew Morton wrote: > On Wed, 27 Jun 2018 12:12:48 -0700 Shakeel Butt <shakeelb@xxxxxxxxxx> wrote: > > > The Linux kernel's memory cgroup allows limiting the memory usage of > > the jobs running on the system to provide isolation between the jobs. > > All the kernel memory allocated in the context of the job and marked > > with __GFP_ACCOUNT will also be included in the memory usage and be > > limited by the job's limit. > > > > The kernel memory can only be charged to the memcg of the process in > > whose context kernel memory was allocated. However there are cases where > > the allocated kernel memory should be charged to the memcg different > > from the current processes's memcg. This patch series contains two such > > concrete use-cases i.e. fsnotify and buffer_head. > > > > The fsnotify event objects can consume a lot of system memory for large > > or unlimited queues if there is either no or slow listener. The events > > are allocated in the context of the event producer. However they should > > be charged to the event consumer. Similarly the buffer_head objects can > > be allocated in a memcg different from the memcg of the page for which > > buffer_head objects are being allocated. > > > > To solve this issue, this patch series introduces mechanism to charge > > kernel memory to a given memcg. In case of fsnotify events, the memcg of > > the consumer can be used for charging and for buffer_head, the memcg of > > the page can be charged. For directed charging, the caller can use the > > scope API memalloc_[un]use_memcg() to specify the memcg to charge for > > all the __GFP_ACCOUNT allocations within the scope. > > This patchset is not showing signs of having been well reviewed at > this time. Could people please take another look? I don't have the mailing list archives for this anymore, but the series as it stands in mmots looks good to me and incorporates all the feedback I remember giving. [ My only gripe really is that it applies current->active_memcg only to kmem charges, not others as well. Right now it doesn't matter, but I can see this costing a kernel developer implementing remote charges for something other than kmem some time to realize. ] Anyway, please feel free to add Acked-by: Johannes Weiner <hannes@xxxxxxxxxxx> for 1/2 and 2/2 plus their two fixlets.
