| … | |
… | |
| 44 | * b) best is not necessarily very good. |
44 | * b) best is not necessarily very good. |
| 45 | * c) it's better than the aio mess, doesn't suffer from the fork problems |
45 | * c) it's better than the aio mess, doesn't suffer from the fork problems |
| 46 | * of linux aio or epoll and so on and so on. and you could do event stuff |
46 | * of linux aio or epoll and so on and so on. and you could do event stuff |
| 47 | * without any syscalls. what's not to like? |
47 | * without any syscalls. what's not to like? |
| 48 | * d) ok, it's vastly more complex, but that's ok, really. |
48 | * d) ok, it's vastly more complex, but that's ok, really. |
| 49 | * e) why 3 mmaps instead of one? one would be more space-efficient, |
49 | * e) why two mmaps instead of one? one would be more space-efficient, |
| 50 | * and I can't see what benefit three would have (other than being |
50 | * and I can't see what benefit two would have (other than being |
| 51 | * somehow resizable/relocatable, but that's apparently not possible). |
51 | * somehow resizable/relocatable, but that's apparently not possible). |
| 52 | * (FIXME: newer kernels can use 2 mmaps only, need to look into this). |
|
|
| 53 | * f) hmm, it's practiclaly undebuggable (gdb can't access the memory, and |
52 | * f) hmm, it's practically undebuggable (gdb can't access the memory, and |
| 54 | * the bizarre way structure offsets are communicated makes it hard to |
53 | * the bizarre way structure offsets are communicated makes it hard to |
| 55 | * just print the ring buffer heads, even *iff* the memory were visible |
54 | * just print the ring buffer heads, even *iff* the memory were visible |
| 56 | * in gdb. but then, that's also ok, really. |
55 | * in gdb. but then, that's also ok, really. |
| 57 | * g) well, you cannot specify a timeout when waiting for events. no, |
56 | * g) well, you cannot specify a timeout when waiting for events. no, |
| 58 | * seriously, the interface doesn't support a timeout. never seen _that_ |
57 | * seriously, the interface doesn't support a timeout. never seen _that_ |
| 59 | * before. sure, you can use a timerfd, but that's another syscall |
58 | * before. sure, you can use a timerfd, but that's another syscall |
| 60 | * you could have avoided. overall, this bizarre omission smells |
59 | * you could have avoided. overall, this bizarre omission smells |
| 61 | * like a µ-optimisation by the io_uring author for his personal |
60 | * like a µ-optimisation by the io_uring author for his personal |
| 62 | * applications, to the detriment of everybody else who just wants |
61 | * applications, to the detriment of everybody else who just wants |
| 63 | * an event loop. but, umm, ok, if that's all, it could be worse. |
62 | * an event loop. but, umm, ok, if that's all, it could be worse. |
| 64 | * (FIXME: jens mentioned timeout commands, need to investigate) |
63 | * (from what I gather form Jens Axboe, it simply didn't occur to him, |
|
|
64 | * and he made good on it by adding an unlimited nuber of timeouts |
|
|
65 | * later :). |
| 65 | * h) there is a hardcoded limit of 4096 outstanding events. okay, |
66 | * h) initially there was a hardcoded limit of 4096 outstanding events. |
| 66 | * at least there is no arbitrary low system-wide limit... |
67 | * later versions not onlyx bump this to 32k, but also can handle |
| 67 | * (FIXME: apparently, this was increased to 32768 in later kernels( |
68 | * an unlimited amount of events, so this only affects the batch size. |
| 68 | * i) unlike linux aio, you *can* register more then the limit |
69 | * i) unlike linux aio, you *can* register more then the limit |
| 69 | * of fd events, and the kernel will "gracefully" signal an |
70 | * of fd events. while early verisons of io_uring signalled an overflow |
| 70 | * overflow, after which you could destroy and recreate the kernel |
71 | * and you ended up getting wet. 5.5+ does not do this anymore. |
| 71 | * state, a bit bigger, or fall back to e.g. poll. thats not |
|
|
| 72 | * totally insane, but kind of questions the point a high |
|
|
| 73 | * performance I/O framework when it doesn't really work |
|
|
| 74 | * under stress. |
|
|
| 75 | * (FIXME: iouring should no longer drop events, need to investigate) |
|
|
| 76 | * j) but, oh my! is has exactly the same bugs as the linux aio backend, |
72 | * j) but, oh my! it had exactly the same bugs as the linux aio backend, |
| 77 | * where some undocumented poll combinations just fail. |
73 | * where some undocumented poll combinations just fail. fortunately, |
| 78 | * so we need epoll AGAIN as a fallback. AGAIN! epoll!! and of course, |
74 | * after finally reaching the author, he was more than willing to fix |
| 79 | * this is completely undocumented, have I mantioned this already? |
75 | * this probably in 5.6+. |
| 80 | * k) overall, the *API* itself is, I dare to say, not a total trainwreck. |
76 | * k) overall, the *API* itself is, I dare to say, not a total trainwreck. |
| 81 | * the big isuess with it are the bugs requiring epoll, which might |
77 | * once the bugs ae fixed (probably in 5.6+), it will be without |
| 82 | * or might not get fixed (do I hold my breath?). |
78 | * competition. |
| 83 | */ |
79 | */ |
| 84 | |
80 | |
| 85 | /* TODO: use internal TIMEOUT */ |
81 | /* TODO: use internal TIMEOUT */ |
| 86 | /* TODO: take advantage of single mmap, NODROP etc. */ |
82 | /* TODO: take advantage of single mmap, NODROP etc. */ |
| 87 | /* TODO: resize cq/sq size independently */ |
83 | /* TODO: resize cq/sq size independently */ |
