On Wed, 24 Mar 2021 16:25:52 -0600 Jens Axboe <axboe@xxxxxxxxx> wrote: > The backstory is that an internal workload complained because it was > using too much CPU, and when I took a look, we had a lot of io_uring > workers going to town. For an async buffered read like workload, I am > normally expecting _zero_ offloads to a worker thread, but this one > had tons of them. I'd drop caches and things would look good again, > but then a minute later we'd regress back to using workers. Turns out > that every minute something was reading parts of the device, which > would add page cache for that inode. I put patches like these in for > our kernel, and the problem was solved. I added the above to the 0/n changelog if tha'ts OK. > Obviously that's not a great story since there are no hard numbers > there, and I'd have to generate those for you! Which I surely can. > While the original premise of the patches was fixing excessive CPU > usage, the general observation is that outside of just using a lot more > CPU, it'll also cause worse latencies as offload to a thread always adds > latency. > > So let me know if you want me to generate some numbers. They will be > artificial, but at least it'll be something outside of a story. We really should back it up with numbers, even if they're handwavy. Particularly because we need to figure out if -stable wants this. What are your feelings on that one?
