lkml.org 
[lkml]   [2019]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 00/14] epoll: support pollable epoll from userspace
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Tue, 11 Jun 2019 16:54:44 +0200 Roman Penyaev <rpenyaev@suse.de> 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@dcvr.yhbt.net/

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 :<

\
 
 \ /
  Last update: 2019-07-27 19:17    [W:0.066 / U:1.484 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site