Re: [PATCH bpf-next v9 2/6] mm, bpf: Introduce try_alloc_pages() for opportunistic page allocation

[Shakeel Butt <shakeel.butt@linux.dev>]

On Wed, Mar 12, 2025 at 11:00:20AM +0100, Vlastimil Babka wrote:
[...]
> 
> But if we can achieve the same without such reserved objects, I think it's
> even better. Performance and maintainability doesn't need to necessarily
> suffer. Maybe it can even improve in the process. E.g. if we build upon
> patches 1+4 and swith memcg stock locking to the non-irqsave variant, we
> should avoid some overhead there (something similar was tried there in the
> past but reverted when making it RT compatible).

In hindsight that revert was the bad decision. We accepted so much
complexity in memcg code for RT without questioning about a real world
use-case. Are there really RT users who want memcg or are using memcg? I
can not think of some RT user fine with memcg limits enforcement
(reclaim and throttling).

I am on the path to bypass per-cpu memcg stocks for RT kernels. The
stats would still need to be careful but I don't see any reason to keep
the complexity in memcg stocks for RT. IMO RT should prefer
predictability over performance, so bypassing memcg stocks should be
fine.