From: Linus Torvalds <torvalds@linux-foundation.org>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: Oleg Nesterov <oleg@redhat.com>,
WangYuli <wangyuli@uniontech.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Christian Brauner <brauner@kernel.org>,
1vier1@web.de
Subject: Re: [RESEND PATCH] fs/pipe: Introduce a check to skip sleeping processes during pipe read/write
Date: Tue, 31 Dec 2024 11:38:17 -0800 [thread overview]
Message-ID: <CAHk-=wjST86WXn2FRYuL7WVqwvdtXPmmsKKCuJviepeSP2=LPg@mail.gmail.com> (raw)
In-Reply-To: <20241231111428.5510-1-manfred@colorfullife.com>
On Tue, 31 Dec 2024 at 03:14, Manfred Spraul <manfred@colorfullife.com> wrote:
>
> Should we add the missing memory barriers and switch to
> wait_queue_active() in front of all wakeup calls?
If we *really* want to optimize this, we could even get rid of the
memory barrier at least on x86, because
(a) mutex_unlock() is a full memory barrier on x86 (it involves a
locked cmpxchg)
(b) the condition is always set inside the locked region
(c) the wakeup is after releasing the lock
but this is architecture-specific (ie "mutex_unlock()" is not
*guaranteed* to be a memory barrier (ie on other architectures it
might be only a release barrier).
We have "smp_mb__after_atomic()" and "smp_mb__after_spinlock()", but
we don't have a "smp_mb__after_mutex_unlock()".
So we'd have to add a new helper or config option.
Anyway, I'm perfectly happy to get these optimizations, but because of
historical trouble in this area, I want any patches to be very clearly
documented.
Oleg's patch to only wake up writers when readers have actually opened
up a slot may not make any actual difference (because readers in
*practice* always do big reads), but I like it because it feels
obviously correct and doesn't have any locking or memory ordering
subtleties (and actually makes the logic more logical and
straightforward).
Linus
next prev parent reply other threads:[~2024-12-31 19:38 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-25 9:42 [RESEND PATCH] fs/pipe: Introduce a check to skip sleeping processes during pipe read/write WangYuli
2024-12-25 13:30 ` Andy Shevchenko
2024-12-25 13:53 ` Kent Overstreet
2024-12-25 16:04 ` Mateusz Guzik
2024-12-25 16:32 ` Kent Overstreet
2024-12-25 17:22 ` Mateusz Guzik
2024-12-25 17:41 ` Kent Overstreet
2024-12-25 15:42 ` WangYuli
2024-12-25 16:00 ` Willy Tarreau
2024-12-25 16:32 ` WangYuli
2024-12-25 16:56 ` Willy Tarreau
2024-12-26 16:00 ` Oleg Nesterov
2024-12-26 19:02 ` Linus Torvalds
2024-12-26 20:11 ` Oleg Nesterov
2024-12-26 20:29 ` Linus Torvalds
2024-12-26 20:57 ` Oleg Nesterov
2024-12-27 15:54 ` Oleg Nesterov
2024-12-27 16:43 ` Oleg Nesterov
2024-12-27 18:39 ` Manfred Spraul
2024-12-28 14:32 ` Oleg Nesterov
2024-12-28 15:22 ` Oleg Nesterov
2024-12-28 16:32 ` Oleg Nesterov
2024-12-28 18:53 ` Manfred Spraul
2024-12-29 11:54 ` Oleg Nesterov
2024-12-28 16:45 ` Manfred Spraul
2024-12-29 11:57 ` Oleg Nesterov
2024-12-29 12:41 ` Manfred Spraul
2024-12-29 13:05 ` Oleg Nesterov
2024-12-29 13:13 ` Oleg Nesterov
2024-12-29 19:54 ` Manfred Spraul
2024-12-30 15:38 ` Oleg Nesterov
2024-12-31 11:14 ` Manfred Spraul
2024-12-31 19:38 ` Linus Torvalds [this message]
2024-12-31 20:24 ` Oleg Nesterov
2024-12-31 22:31 ` Linus Torvalds
2025-01-02 13:57 ` Oleg Nesterov
2025-01-04 21:15 ` RFC: Checkpatch: Introduce list of functions that need memory barriers Manfred Spraul
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-=wjST86WXn2FRYuL7WVqwvdtXPmmsKKCuJviepeSP2=LPg@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=1vier1@web.de \
--cc=brauner@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.com \
--cc=oleg@redhat.com \
--cc=wangyuli@uniontech.com \
/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).