axboe changed the topic of #io_uring to: io_uring development discussion | Logs: https://oftc.irclog.whitequark.org/io_uring
erwan_taf has quit [Ping timeout: 480 seconds]
dylanza has quit [Remote host closed the connection]
dylanza has joined #io_uring
haoxu has joined #io_uring
<haoxu> Hi Jens, I've done some testing to uringlet, I found the in low iodepth, uringlet is slow because it has many schedule out and wakeup. When iodepth is 1: For the current iowq framework, it just queues 1 sqe-->sqe exec inline(since almost no blocking points)-->reap the cqe. While for uringlet, it queues 1 sqe-->sleep, a worker wakes up and exec the sqe and then wake up the original context. That costs some time.
<haoxu> I change the fio code to poll the cqring rather than sleep and wait, uringlet almost achieve the same iops as the current implementation. But surely uringlet consumes more cpu since fio is busying looping there
haoxu has quit [Remote host closed the connection]
haoxu has joined #io_uring
<haoxu> the peak IOPS of uringlet is larger than the current iowq implementation
haoxu has quit [Remote host closed the connection]
<_axboe> haoxu: hope you see this, but thanks, I'll take a look! been traveling this week (plumbers conference and maintainers summit), so mostly been away and not very active in general
haoxu has joined #io_uring
<_axboe> haoxu: replied earlier, should be in the log
<_axboe> looks nice - I'll take a closer look at this when flying home tomorrow
<_axboe> perhaps you can respin the patchset? and email it out?
<haoxu> sure, that's what I'm gona do
<_axboe> excellent
<_axboe> numbers look really nice, would be great if you could include your actual test case too
<haoxu> gotcha
<haoxu> I'll paste the test method in the cover-letter
<haoxu> it's actually fio buffered randwrite to a file, with bs=1024, and time=180s
<haoxu> I changed the wait event part to busy waiting
<haoxu> The thing is it costs much cpu
<haoxu> in iodepth=1, almost twice
<haoxu> I also tried to do "original context block-->abort, rise a worker to take the request", but failed.
<haoxu> that way, we have to roll back the effect we've done from the start of that blocked request to the blocking pointer, like if we may allocate memory during this period and we cannot just simply abort from schedule(), we also cannot simply return to the code path...
<haoxu> anyway, thanks for replying in this busy time. see you later
dylanza has quit [Remote host closed the connection]
dylanza has joined #io_uring
haoxu has quit [Remote host closed the connection]