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.
