From: David Laight <David.Laight@ACULAB.COM>
To: 'Jason Baron' <jbaron@akamai.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Alexander Viro" <viro@zeniv.linux.org.uk>, Heiher <r@hev.cc>,
Roman Penyaev <rpenyaev@suse.de>,
Khazhismel Kumykov <khazhy@google.com>,
Davidlohr Bueso <dbueso@suse.de>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: RE: [PATCH] epoll: ensure ep_poll() doesn't miss wakeup events
Date: Sun, 3 May 2020 13:05:24 +0000 [thread overview]
Message-ID: <c2921e66bf3a4edfaa667c32abbefebf@AcuMS.aculab.com> (raw)
In-Reply-To: <1588360533-11828-1-git-send-email-jbaron@akamai.com>
From: Jason Baron
> Sent: 01 May 2020 20:16
>
> Now that the ep_events_available() check is done in a lockless way, and
> we no longer perform wakeups from ep_scan_ready_list(), we need to ensure
> that either ep->rdllist has items or the overflow list is active. Prior to:
> commit 339ddb53d373 ("fs/epoll: remove unnecessary wakeups of nested
> epoll"), we did wake_up(&ep->wq) after manipulating the ep->rdllist and the
> overflow list. Thus, any waiters would observe the correct state. However,
> with that wake_up() now removed we need to be more careful to ensure that
> condition.
I'm wondering how much all this affects the (probably) more common
case of a process reading events from a lot of sockets in 'level'
mode.
Even the change to a rwlock() may have had an adverse effect
on such programs.
In 'level' mode it doesn't make any sense to have multiple
readers of the event queue.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
prev parent reply other threads:[~2020-05-03 13:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-01 19:15 [PATCH] epoll: ensure ep_poll() doesn't miss wakeup events Jason Baron
2020-05-01 21:02 ` Roman Penyaev
2020-05-01 22:09 ` Jason Baron
2020-05-03 10:24 ` Roman Penyaev
2020-05-04 4:29 ` Jason Baron
2020-05-04 4:59 ` Jason Baron
2020-05-04 9:40 ` Roman Penyaev
2020-05-03 13:05 ` David Laight [this message]
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=c2921e66bf3a4edfaa667c32abbefebf@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=akpm@linux-foundation.org \
--cc=dbueso@suse.de \
--cc=jbaron@akamai.com \
--cc=khazhy@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=r@hev.cc \
--cc=rpenyaev@suse.de \
--cc=stable@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.