On Wed 18-12-24 17:53:50, Alexei Starovoitov wrote: > 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. Yes, it is an optimization to avoid charging the page_counter directly which involves atomic operations and that scales with the depth of the hierarchy. So yes, it is a batching mechanism to optimize a common case where the same memcg charges on the same cpu several allocations which is a common case. > 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. Right > In RT the unlucky part is in_hardirq or in_nmi, since spin_trylock > doesn't really work in those conditions as Steven explained. Right All that being said, the message I wanted to get through is that atomic (NOWAIT) charges could be trully reentrant if the stock local lock uses trylock. We do not need a dedicated gfp flag for that now. -- Michal Hocko SUSE Labs
