linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roman Penyaev <rpenyaev@suse.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Peter Zijlstra <peterz@infradead.org>,
	Azat Khuzhin <azat@libevent.org>, Eric Wong <e@80x24.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux List Kernel Mailing <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v5 00/14] epoll: support pollable epoll from userspace
Date: Tue, 25 Jun 2019 13:19:04 +0200	[thread overview]
Message-ID: <f0d2c829c72c63d08c8df46d2d32c2af@suse.de> (raw)
In-Reply-To: <CAHk-=wgQaCDiH09ocVA=74ceg9XyS=kRDF5Hi=783shCaKVRWg@mail.gmail.com>

On 2019-06-24 22:38, Linus Torvalds wrote:
> On Mon, Jun 24, 2019 at 10:42 PM Roman Penyaev <rpenyaev@suse.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?

This http tool is a singlethreaded test, i.e. client and server
work as a standalone processes and each has a single event thread
for everything.

According to what I saw there, is that events come slowly (or event
loop acts faster?), so when time has come to harvest events there
is nothing, we take a slow path and go to kernel in order to sleep.
That does not explain the main "why", unfortunately.

I would like to retest that adding more clients to the server, thus
server is more likely to observe events in a ring, avoiding sleep.

--
Roman


  reply	other threads:[~2019-06-25 11:19 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-24 14:41 Roman Penyaev
2019-06-24 14:41 ` [PATCH v5 01/14] epoll: move private helpers from a header to the source Roman Penyaev
2019-06-24 14:41 ` [PATCH v5 02/14] epoll: introduce user structures for polling from userspace Roman Penyaev
2019-06-24 14:41 ` [PATCH v5 03/14] epoll: allocate user header and user events ring " Roman Penyaev
2019-06-24 14:41 ` [PATCH v5 04/14] epoll: some sanity flags checks for epoll syscalls " Roman Penyaev
2019-06-24 14:41 ` [PATCH v5 05/14] epoll: offload polling to a work in case of epfd polled " Roman Penyaev
2019-06-24 14:41 ` [PATCH v5 06/14] epoll: introduce helpers for adding/removing events to uring Roman Penyaev
2019-06-24 14:41 ` [PATCH v5 07/14] epoll: call ep_add_event_to_uring() from ep_poll_callback() Roman Penyaev
2019-06-24 14:41 ` [PATCH v5 08/14] epoll: support polling from userspace for ep_insert() Roman Penyaev
2019-06-24 14:41 ` [PATCH v5 09/14] epoll: support polling from userspace for ep_remove() Roman Penyaev
2019-06-24 14:41 ` [PATCH v5 10/14] epoll: support polling from userspace for ep_modify() Roman Penyaev
2019-06-24 14:41 ` [PATCH v5 11/14] epoll: support polling from userspace for ep_poll() Roman Penyaev
2019-06-24 14:41 ` [PATCH v5 12/14] epoll: support mapping for epfd when polled from userspace Roman Penyaev
2019-06-24 14:41 ` [PATCH v5 13/14] epoll: implement epoll_create2() syscall Roman Penyaev
2019-06-24 16:14   ` Arnd Bergmann
2019-06-24 16:25     ` Roman Penyaev
2019-06-25 18:29   ` Eric Wong
2019-06-24 14:41 ` [PATCH v5 14/14] kselftest: add uepoll-test which tests polling from userspace Roman Penyaev
2019-06-24 20:38 ` [PATCH v5 00/14] epoll: support pollable epoll " Linus Torvalds
2019-06-25 11:19   ` Roman Penyaev [this message]
2019-06-25  0:24 ` Eric Wong
2019-06-25 11:07   ` Roman Penyaev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f0d2c829c72c63d08c8df46d2d32c2af@suse.de \
    --to=rpenyaev@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=azat@libevent.org \
    --cc=e@80x24.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    --subject='Re: [PATCH v5 00/14] epoll: support pollable epoll from userspace' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).