> On 30. Sep 2024, at 20:46, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, 30 Sept 2024 at 10:35, Christian Theune <ct@xxxxxxxxxxxxxxx> wrote: >> >> Sep 27 00:51:20 <redactedhostname>13 kernel: folio_wait_bit_common+0x13f/0x340 >> Sep 27 00:51:20 <redactedhostname>13 kernel: folio_wait_writeback+0x2b/0x80 > > Gaah. Every single case you point to is that folio_wait_writeback() case. > > And this might be an old old annoyance. I’m being told that I’m somewhat of a truffle pig for dirty code … how long ago does “old old” refer to, btw? > […] > IOW, this code is known-broken and might have extreme unfairness > issues (although I had blissfully forgotten about it), because while > the actual writeback *bit* itself is set and cleared atomically, the > wakeup for the bit is asynchronous and can be delayed almost > arbitrarily, so you can get basically spurious wakeups that were from > a previous bit clear. I wonder whether the extreme unfairness gets exacerbated when in a cgroup throttled context … It’s a limited number of workloads we have seen this with, some of which are parallelized and others aren’t. (and I guess non-parallelized code shouldn’t suffer much from this?) Maybe I can reproduce this more easily and ... > So the code here is questionable, and might cause some issues, but the > starvation of folio_wait_writeback() can't explain _all_ the cases you > see. … also get you more data and dig for maybe more cases more systematically. Anything particular you’d like me to look for? Any specific additional data points that would help? We’re going to keep with 6.11 in staging and avoid rolling it out to the production machines for now. Christian -- Christian Theune · ct@xxxxxxxxxxxxxxx · +49 345 219401 0 Flying Circus Internet Operations GmbH · https://flyingcircus.io Leipziger Str. 70/71 · 06108 Halle (Saale) · Deutschland HR Stendal HRB 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick
