On Wed 12-03-25 12:06:10, Shakeel Butt wrote: > 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 do not think that there is any reasonable RT workload that would use memcg limits or other memcg features. On the other hand it is not unusual to have RT and non-RT workloads mixed on the same machine. They usually use some sort of CPU isolation to prevent from CPU contention but that doesn't help much if there are other resources they need to contend for (like shared locks). > I am on the path to bypass per-cpu memcg stocks for RT kernels. That would cause regressions for non-RT tasks running on PREEMPT_RT kernels, right? -- Michal Hocko SUSE Labs
