It'd be kinda awesome if we could have an io_uring with multiple submission queues/rings, but only one completion queue/ring. With the ability to map the submission queue only in one process, but the completion queue in multiple.
CC: @axboe
-
Show this thread
-
Replying to @AndresFreundTec
Agree, it would be pretty nifty! Would not be hard to do, I think the hardest part would actually be the liburing side of it.
1 reply 0 retweets 2 likes -
Replying to @axboe
If it'd require more manual work to set up, it'd be fair enough. Though it turns out that the contention I was just seeing was unnecessary. Still bothersome to have to be careful to hold submission side lock until all submissions have to be consumed by kernel (due to mm/fds).
1 reply 0 retweets 0 likes -
Replying to @AndresFreundTec
It'd be trivial to ensure things are correct and eliminate any need to think about locking, which is always a win on the application side imho. I'll have to think about it a bit.
2 replies 0 retweets 1 like -
Replying to @axboe
Cool! Random update: FWIW, got PG to be competitive with io_uring based AIO for several workloads (but file appending is really bad right now). But only when using DIO, buffered has considerably higher CPU usage/contention.
2 replies 0 retweets 1 like -
Replying to @AndresFreundTec @axboe
The slowdown for buffered IO is noticeable both when the data is in the page cache (because submission lock is held while copying all the data), and when not (the number of io-wq workers causing CPU overhead, partially due to contention).
1 reply 0 retweets 0 likes -
Replying to @AndresFreundTec
For the read side, it should be no slower than read(2) eg if cached, but if you need locking held over the copy, then that's definitely a concern. For read side buffered IO, my goal is to make this work through page waitqueue callbacks and eliminate the need for io-wq.
2 replies 0 retweets 0 likes -
Replying to @axboe
Buffered reads via io-u that need to actually execute IO cause kernel-side contention, particularly around bringing the page into page cache. Re waitqueue callbacks: That sounds awesome.
1 reply 0 retweets 1 like -
-
Replying to @AndresFreundTec
You should re-run that test case with my async-buffered.4 branch pulled in!
1 reply 0 retweets 1 like
Will try to. Really need to get another decent drive that I can pass through a VM to do testing like this without having to reboot my workstation.
-
-
Replying to @AndresFreundTec @axboe
Also just generally for development of the aio (on linux using io-uring) patch for postgres. The Samsung 970 Pro I'm currently using for that isn't bad, but it's quite possible to reach its limits. And the performance is a bit too variable over time for benchmarking.
1 reply 0 retweets 0 likes -
Replying to @AndresFreundTec @axboe
Did you try overprovisioning the drive (by limiting the available space via either NVME namespacing, or partitioning the pre-defined namespace, if the device doesn't support namespace mgmt)? That solved most performance consistency problems for us with consumer devices.
1 reply 0 retweets 0 likes - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.