fwd to bpf list for BPF CI to pick it up. ---------- Forwarded message --------- From: Vlastimil Babka <vbabka@xxxxxxx> Date: Mon, Mar 10, 2025 at 12:03 PM Subject: Re: [linux-next:master] [memcg] 01d37228d3: netperf.Throughput_Mbps 37.9% regression To: Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> Cc: kernel test robot <oliver.sang@xxxxxxxxx>, Alexei Starovoitov <ast@xxxxxxxxxx>, <oe-lkp@xxxxxxxxxxxxxxx>, kbuild test robot <lkp@xxxxxxxxx>, Michal Hocko <mhocko@xxxxxxxx>, Shakeel Butt <shakeel.butt@xxxxxxxxx>, open list:CONTROL GROUP (CGROUP) <cgroups@xxxxxxxxxxxxxxx>, linux-mm <linux-mm@xxxxxxxxx> On 3/10/25 11:56, Alexei Starovoitov wrote: > On Mon, Mar 10, 2025 at 11:34 AM Vlastimil Babka <vbabka@xxxxxxx> wrote: >> >> On 3/10/25 11:18, Alexei Starovoitov wrote: >> >> because this will affect the refill even if consume_stock() fails not due to >> >> a trylock failure (which should not be happening), but also just because the >> >> stock was of a wrong memcg or depleted. So in the nowait context we deny the >> >> refill even if we have the memory. Attached patch could be used to see if it >> >> if fixes things. I'm not sure about the testcases where it doesn't look like >> >> nowait context would be used though, let's see. >> > >> > Not quite. >> > GFP_NOWAIT includes __GFP_KSWAPD_RECLAIM, >> > so gfpflags_allow_spinning() will return true. >> >> Uh right, it's the new gfpflags_allow_spinning(), not the >> gfpflags_allow_blocking() I'm used to and implicitly assumed, sorry. >> >> But then it's very simple because it has a bug: >> gfpflags_allow_spinning() does >> >> return !(gfp_flags & __GFP_RECLAIM); >> >> should be !! > > Ouch. > So I accidentally exposed the whole linux-next to this stress testing > of new trylock facilities :( > But the silver lining is that this is the only thing that blew up :) > Could you send a patch or I will do it later today. OK ----8<----
