On 12/22/19 7:23 AM, Marc Lehmann wrote: > On Sat, Dec 21, 2019 at 06:45:20PM +0000, Benjamin Mahler > <[email protected]> wrote: >> Sounds like some of the iouring findings are surprising to Jens (the >> author). > > Well, I mailed him personally (no response), opened bug reports on > bugzilla.kernel.org (no response), and even found a discussion on the most > pressing problem on the linux-kernel list that I found after debugging > this in the kernel, from where I paraphrased linus's reaction. > > https://bugzilla.kernel.org/show_bug.cgi?id=204081 that bug > https://bugzilla.kernel.org/show_bug.cgi?id=204065 oops bug > https://bugzilla.kernel.org/show_bug.cgi?id=204085 linux aio potential > security bug (not iouring)
Well, none of these have me on the CC list, and they are filed against the aio subsystem. There's no way I'd see these, and I'm pretty sure the person listed for aio has long since moved elsewhere. For bug reports, always at least CC the person, otherwise you have no guarantee they are seen! > https://lore.kernel.org/patchwork/patch/1047453/ the problem in linux aio, > same in io_uring > "I guess nobody really expects to use aio_poll on anything but a socket or > something?" I'm not subscribed to linux-kernel, I need to be CC'ed on emails to see them. Otherwise I couldn't do anything but read emails, and I do have other things to do. > I understand we are all busy, and bugzilla.kernel.org sems to work a lot > like the usenet wizard groups (saome areas are just blackholes, such as > btrfs and aio/iouring, others are quite active, such as ext4 :), but on > the other hand, Jens really should not be that _surprised_ :) You may think this is fair, but it's definitely not. First of all, you bundle aio/iouring, they are totally not the same thing. I don't file a bug report for libevent and call it libev/libevent and expect you to find it. I've replied to ALL bug reports I've received, and taken care of them. > Now, if this is what gets his attention, just the better, a working and > performant io_uring could finally get us out of epoll hell, although > kqueue still clearly leads the design, despite its cumbersome API. > > In any case, I put most of my findings into the comments at the top of > ther source files - in my panic in trying to rescue what is clearly the > best event api in linux so far, I even started to embed epoll to *maybe* > get it into a working state, which kind of gets us the worst of all > worlds: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__cvs.schmorp.de_libev_ev-5Fiouring.c&d=DwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=cK1a7KivzZRh1fKQMjSm2A&m=YL0hyN7rczX2id-XEDVKfTKUvACqEeGAK2-3FUwHsdY&s=ZO_rZs9vCG9MPUeiSp36c4PJnR9Vwo_ApX1WtQRTy1s&e= > > https://urldefense.proofpoint.com/v2/url?u=http-3A__cvs.schmorp.de_libev_ev-5Flinuxaio.c&d=DwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=cK1a7KivzZRh1fKQMjSm2A&m=YL0hyN7rczX2id-XEDVKfTKUvACqEeGAK2-3FUwHsdY&s=PR1PkYJ6hDC1GmCy4gwVwibfMy44hp7nbIahCJ7txXU&e= > I'll take a look, but as you probably know, timing is unfortunate with the holidays coming up. I'll wrapping things up tomorrow, then not much after that until after the new year. Just to set expectations. >> Is there a benchmark he can run to look into this? > > Haven't tried it, but the libevent/libev behcmark should show the bad > performance compared to epoll (and even poll/select): > > https://urldefense.proofpoint.com/v2/url?u=http-3A__data.plan9.de_bench.c&d=DwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=cK1a7KivzZRh1fKQMjSm2A&m=YL0hyN7rczX2id-XEDVKfTKUvACqEeGAK2-3FUwHsdY&s=0XjVe_PVhre4LW1uHGa75QNgOJA3DCrSXStx5tZqP9g&e= > > > Can be compiled in a libev directory: > > gcc -O3 -DNATIVE=1 -DEV_MULTIPLICITY=0 -o bench bench.c -I. ev.c event.c -lm > > And then, for e.g. 10000 fds: > > LIBEV_FLAGS=1 ./bench -n 10000 -a 100 # select > LIBEV_FLAGS=4 ./bench -n 10000 -a 100 # epoll > LIBEV_FLAGS=128 ./bench -n 10000 -a 100 # iouring > > I don't actually remember what exactly I benchmarked (it was a number of > throwaway oneliners), but between kernel oopses, having to use epoll, the > issues with io_uring under high load, the abysmal state of documentation > and so on, I didn't really bother to play with it much more in its current > state. I'll try that too. 5.1 is ancient, and the first release with io_uring. I would not expect too much, it's a lot more mature now. >> Do you have more explanation about "silently ignore parts of the requested >> events on an undocumented subset of file description types"? > > I hope all required info is in the bugzilla bug report. > > If anybody wants more information, I will happily provide more - it's just > that I already made a very large investment just to be disappointed, so I'd > like to have a perspective on whether its really worth it to invest more time > in this backend. I'll check the material, provided the above links have what I need to take a look at this. -- Jens Axboe _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/mailman/listinfo/libev
