linux-kernel - Re: [PATCH v4 00/14] epoll: support pollable epoll from userspace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20190727171657.cisalgn3wfs5opyi@dcvr>
Date:   Sat, 27 Jul 2019 17:16:57 +0000
From:   Eric Wong <e@...24.org>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     Roman Penyaev <rpenyaev@...e.de>,
        Al Viro <viro@...iv.linux.org.uk>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Azat Khuzhin <azat@...event.org>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 00/14] epoll: support pollable epoll from userspace

Andrew Morton <akpm@...ux-foundation.org> wrote:
> On Tue, 11 Jun 2019 16:54:44 +0200 Roman Penyaev <rpenyaev@...e.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 :<