Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Reclamation interactions with RCU

[Yosry Ahmed <yosryahmed@google.com>]

On Thu, Feb 29, 2024 at 6:49 PM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Thu, Feb 29, 2024 at 09:39:17PM -0500, Kent Overstreet wrote:
> > On Fri, Mar 01, 2024 at 01:16:18PM +1100, NeilBrown wrote:
> > > Insisting that GFP_KERNEL allocations never returned NULL would allow us
> > > to remove a lot of untested error handling code....
> >
> > If memcg ever gets enabled for all kernel side allocations we might
> > start seeing failures of GFP_KERNEL allocations.
>
> Why would we want that behaviour?  A memcg-limited allocation should
> behave like any other allocation -- block until we've freed some other
> memory in this cgroup, either by swap or killing or ...

I am not closely following this thread (although it is very
interesting), but I don't think the same rules fully apply for
memcg-limited allocations. Specifically, because the scope of the OOM
killer and available resources is limited to the subtree of the memcg
that hit its limit. Consider a case where a memcg is full of page
cache memory that is mlock()'s by a process in another memcg, or full
of tmpfs memory and there is no swap (or swap limit is reached).

You can get more creative with this too, start a process in memcg A,
allocate some anon memory, move the process to memcg B. Now if you
cannot swap, you cannot reclaim the memory from memcg A and killing
everything in memcg A doesn't help.