[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgQaCDiH09ocVA=74ceg9XyS=kRDF5Hi=783shCaKVRWg@mail.gmail.com>
Date: Tue, 25 Jun 2019 04:38:06 +0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Roman Penyaev <rpenyaev@...e.de>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Al Viro <viro@...iv.linux.org.uk>,
Peter Zijlstra <peterz@...radead.org>,
Azat Khuzhin <azat@...event.org>, Eric Wong <e@...24.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux List Kernel Mailing <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 00/14] epoll: support pollable epoll from userspace
On Mon, Jun 24, 2019 at 10:42 PM Roman Penyaev <rpenyaev@...e.de> wrote:
>
> So harvesting events from userspace gives 15% gain. Though bench_http
> is not ideal benchmark, but at least it is the part of libevent and was
> easy to modify.
>
> Worth to mention that uepoll is very sensible to CPU, e.g. the gain above
> is observed on desktop "Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz", but on
> "Intel(R) Xeon(R) Silver 4110 CPU @ 2.10GHz" measurements are almost the
> same for both runs.
Hmm. 15% may be big in a big picture thing, but when it comes to what
is pretty much a micro-benchmark, I'm not sure how meaningful it is.
And the CPU sensitivity thing worries me. Did you check _why_ it
doesn't seem to make any difference on the Xeon 4110? Is it just
because at that point the machine has enough cores that you might as
well just sit in epoll() in the kernel and uepoll doesn't give you
much? Or is there something else going on?
Because this is a big enough change and UAPI thing that it's a bit
concerning if there isn't a clear and unambiguous win.
Linus
Powered by blists - more mailing lists