Upgraded Kernel. Now my experimental io_uring branch of postgres is broken :( Different backends, inheriting io_urings from the postmaster, aren't allowed to submit events anymore. Only consume. Hm.
-
Show this thread
-
Replying to @AndresFreundTec
Ah saw the email. Yes, I think we should revert this change for now. That’ll give us some time to discuss it more thoroughly.
1 reply 0 retweets 4 likes -
Replying to @axboe
Cool. Found another fork related one (fcb323cc53e2). I guess I better contribute a liburing test for sharing a uring across a fork... Shoul've upgrade the kernel earlier in the cycle :(
1 reply 0 retweets 0 likes -
Replying to @AndresFreundTec
Your situation is unique in that you're sharing across forks, so yeah would be great to have actual test cases for that in liburing. Always nice to test early, but test cases are better since it means I don't have to rely on others testing early.
1 reply 0 retweets 3 likes -
Replying to @axboe
Ok, will try to write one. Do you think sharing between processes is a bad path to go down, given the reasoning I outlined (https://lore.kernel.org/io-uring/20200126055457.5w4f5jyhkic7cixu@alap3.anarazel.de/ …)? I'd rather not work towards building on top of io_uring, that the author of uring finds too constraining for future development.
1 reply 0 retweets 0 likes -
Replying to @AndresFreundTec
Your sharing is fine, I have no issue with that. My only concern with sharing, and this isn't specific to across fork, is the implied extra overhead in terms of synchronization you need to have. I've got some ideas to improve that situation, though.
2 replies 0 retweets 0 likes -
Replying to @axboe
Yea, I don't like that overhead either. It's not a bad price to pay to have to do it for journal interleaved writes - the savings are so big. But being restricted in the number of uring instances due to the memlock limits is quite painful for other IO.
2 replies 0 retweets 0 likes
The code for that doesn't yet work, but my plan is to have a few urings around that aren't *commonly* going to be shared. So processes not busy doing IO don't hog a full (optimal would be two) urings, the locking is uncontended, but we still can complete their IO if necessary.
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.