linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Petr Mladek <pmladek@suse.com>
Cc: John Ogness <john.ogness@linutronix.de>,
	Sergey Senozhatsky <senozhatsky@chromium.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Jan Kara <jack@suse.cz>, Peter Zijlstra <peterz@infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] printk for 5.19
Date: Thu, 26 May 2022 10:13:29 -0700	[thread overview]
Message-ID: <CAHk-=wjny_OCPeBfr0uLzcMsAK2aa1TX3UPkp2V2scLD4g=7mw@mail.gmail.com> (raw)
In-Reply-To: <Yo9t9Vg/DpvMqCs7@alley>

On Thu, May 26, 2022 at 5:09 AM Petr Mladek <pmladek@suse.com> wrote:
>
> Yeah, it is a shame. I have met code with exclusive waiters only once,
> 8 years ago and completely forgot about it.

Yeah, the exclusive waiters thing is quite unusual, and not a normal pattern.

It's basically only used for a very few performance-critical cases
where the "multiple readers, but only one writer should wake things
up" can happen.

And it's rare. It's things like "accept()" on a socket - where it's
common to have a lot of threads waiting for a new connection, but you
don't want to wake them all just because one new connection comes in,
because only one of them will successfully take it.

There are not very many patterns like that where you have that "many
people waiting for the same thing, only one will get it". It happens
for socket readers (kind of like accept, but for the "UDP packet with
command comes in"), or with things like pipes (which people use for
similar things and distribute work to potentially lots of threads
through a pipe).

So the common pattern tends to be "some event that gets a threaded
server using one thread to complete", but there just aren't that many
of those cases.

It _could_ also be used for things like locking (ie think "lock
release wakes up waiter"), but I think all our lock primitives end up
doing their wakeup routines at a lower level (ie using
"wake_up_process()" directly) so those don't actually use it.

End result: the exclusive waiters are an important case, but they are
rare - and thus the "all()" version of wakeup is also quite rare.

                        Linus

  reply	other threads:[~2022-05-26 17:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-23 13:21 [GIT PULL] printk for 5.19 Petr Mladek
2022-05-25 18:09 ` Linus Torvalds
2022-05-25 22:02   ` John Ogness
2022-05-26 12:09     ` Petr Mladek
2022-05-26 17:13       ` Linus Torvalds [this message]
2022-05-25 18:37 ` pr-tracker-bot

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='CAHk-=wjny_OCPeBfr0uLzcMsAK2aa1TX3UPkp2V2scLD4g=7mw@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=jack@suse.cz \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    /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 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).