Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 11 Jun 2019 16:54:44 +0200 Roman Penyaev <rpenyaev@xxxxxxx> wrote: > > In order to measure polling from userspace libevent was modified [1] and > > bench_http benchmark (client and server) was used: > > > > o EPOLLET, original epoll: > > > > 20000 requests in 0.551306 sec. (36277.49 throughput) > > Each took about 5.54 msec latency > > 1600000bytes read. 0 errors. > > > > o EPOLLET + polling from userspace: > > > > 20000 requests in 0.475585 sec. (42053.47 throughput) > > Each took about 4.78 msec latency > > 1600000bytes read. 0 errors. > > It would be useful to include some words which describe the > significance of this to real-world userspace. If a real application is > sped up 0.000000001% then this isn't very exciting ;) Agreed. I've put my wfcqueue changes from years back on hold because I couldn't show a meaningful improvement in real-world cases: https://lore.kernel.org/lkml/20130401183118.GA9968@xxxxxxxxxxxxx/ Roman's changes have me interested in seeing how my previous changes would stack up (no UAPI changes required). I've been looking for time to forward port my wfcqueue work to the current kernel (but public-inbox takes priority; not that I have much time for that). On the userspace side; I'm not sure any widely-used open source project is really impacted by epoll performance... Most everybody seems to use level-trigger :<
