--- libev/ev_iouring.c 2019/12/28 07:39:18 1.17 +++ libev/ev_iouring.c 2020/06/08 11:15:59 1.22 @@ -1,7 +1,7 @@ /* * libev linux io_uring fd activity backend * - * Copyright (c) 2019 Marc Alexander Lehmann + * Copyright (c) 2019-2020 Marc Alexander Lehmann * All rights reserved. * * Redistribution and use in source and binary forms, with or without modifica- @@ -46,11 +46,10 @@ * of linux aio or epoll and so on and so on. and you could do event stuff * without any syscalls. what's not to like? * d) ok, it's vastly more complex, but that's ok, really. - * e) why 3 mmaps instead of one? one would be more space-efficient, - * and I can't see what benefit three would have (other than being + * e) why two mmaps instead of one? one would be more space-efficient, + * and I can't see what benefit two would have (other than being * somehow resizable/relocatable, but that's apparently not possible). - * (FIXME: newer kernels can use 2 mmaps only, need to look into this). - * f) hmm, it's practiclaly undebuggable (gdb can't access the memory, and + * f) hmm, it's practically undebuggable (gdb can't access the memory, and * the bizarre way structure offsets are communicated makes it hard to * just print the ring buffer heads, even *iff* the memory were visible * in gdb. but then, that's also ok, really. @@ -61,25 +60,22 @@ * like a ยต-optimisation by the io_uring author for his personal * applications, to the detriment of everybody else who just wants * an event loop. but, umm, ok, if that's all, it could be worse. - * (FIXME: jens mentioned timeout commands, need to investigate) - * h) there is a hardcoded limit of 4096 outstanding events. okay, - * at least there is no arbitrary low system-wide limit... - * (FIXME: apparently, this was increased to 32768 in later kernels( + * (from what I gather from the author Jens Axboe, it simply didn't + * occur to him, and he made good on it by adding an unlimited number + * of timeouts later :). + * h) initially there was a hardcoded limit of 4096 outstanding events. + * later versions not only bump this to 32k, but also can handle + * an unlimited amount of events, so this only affects the batch size. * i) unlike linux aio, you *can* register more then the limit - * of fd events, and the kernel will "gracefully" signal an - * overflow, after which you could destroy and recreate the kernel - * state, a bit bigger, or fall back to e.g. poll. thats not - * totally insane, but kind of questions the point a high - * performance I/O framework when it doesn't really work - * under stress. - * (FIXME: iouring should no longer drop events, need to investigate) - * j) but, oh my! is has exactly the same bugs as the linux aio backend, - * where some undocumented poll combinations just fail. - * so we need epoll AGAIN as a fallback. AGAIN! epoll!! and of course, - * this is completely undocumented, have I mantioned this already? + * of fd events. while early verisons of io_uring signalled an overflow + * and you ended up getting wet. 5.5+ does not do this anymore. + * j) but, oh my! it had exactly the same bugs as the linux aio backend, + * where some undocumented poll combinations just fail. fortunately, + * after finally reaching the author, he was more than willing to fix + * this probably in 5.6+. * k) overall, the *API* itself is, I dare to say, not a total trainwreck. - * the big isuess with it are the bugs requiring epoll, which might - * or might not get fixed (do I hold my breath?). + * once the bugs ae fixed (probably in 5.6+), it will be without + * competition. */ /* TODO: use internal TIMEOUT */ @@ -462,6 +458,7 @@ struct io_uring_sqe *sqe = iouring_sqe_get (EV_A); sqe->opcode = IORING_OP_POLL_ADD; sqe->fd = fd; + sqe->addr = 0; sqe->user_data = (uint32_t)fd | ((__u64)(uint32_t)anfds [fd].egen << 32); sqe->poll_events = (nev & EV_READ ? POLLIN : 0) @@ -522,7 +519,6 @@ if (ecb_expect_false (res < 0)) { /*TODO: EINVAL handling (was something failed with this fd)*/ - /*TODO: EBUSY happens when?*/ if (res == -EBADF) {