On Wed, Dec 18, 2024 at 3:32 AM Michal Hocko <mhocko@xxxxxxxx> wrote: > > On Tue 17-12-24 19:07:17, alexei.starovoitov@xxxxxxxxx wrote: > > From: Alexei Starovoitov <ast@xxxxxxxxxx> > > > > Teach memcg to operate under trylock conditions when > > spinning locks cannot be used. > > Can we make this trylock unconditional? I hope I am not really missing > anything important but if the local_lock is just IRQ disabling on !RT. > For RT this is more involved but does it make sense to spin/sleep on the > cache if we can go ahead and charge directly to counters? I mean doesn't > this defeat the purpose of the cache in the first place? memcg folks please correct me. My understanding is that memcg_stock is a batching mechanism. Not really a cache. If we keep charging the counters directly the performance will suffer due to atomic operations and hierarchy walk. Hence I had to make sure consume_stock() is functioning as designed and fallback when unlucky. In !RT case the unlucky part can only happen in_nmi which should be very rare. In RT the unlucky part is in_hardirq or in_nmi, since spin_trylock doesn't really work in those conditions as Steven explained. Sebastian mentioned that he's working on removing preempt_disable() from tracepoints. That should help bpf greatly too.
