From: Al Viro <viro@zeniv.linux.org.uk>
To: Matthew Wilcox <willy@infradead.org>
Cc: maobibo <maobibo@loongson.cn>,
Hongchen Zhang <zhanghongchen@loongson.cn>,
Andrew Morton <akpm@linux-foundation.org>,
David Howells <dhowells@redhat.com>,
Sedat Dilek <sedat.dilek@gmail.com>,
"Christian Brauner (Microsoft)" <brauner@kernel.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Eric Dumazet <edumazet@google.com>,
"Fabio M. De Francesco" <fmdefrancesco@gmail.com>,
Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] pipe: use __pipe_{lock,unlock} instead of spinlock
Date: Mon, 16 Jan 2023 21:10:37 +0000 [thread overview]
Message-ID: <Y8W9TR5ifZmRADLB@ZenIV> (raw)
In-Reply-To: <Y8TUqcSO5VrbYfcM@casper.infradead.org>
On Mon, Jan 16, 2023 at 04:38:01AM +0000, Matthew Wilcox wrote:
> On Mon, Jan 16, 2023 at 11:16:13AM +0800, maobibo wrote:
> > Hongchen,
> >
> > I have a glance with this patch, it simply replaces with
> > spinlock_irqsave with mutex lock. There may be performance
> > improvement with two processes competing with pipe, however
> > for N processes, there will be complex context switches
> > and ipi interruptts.
> >
> > Can you find some cases with more than 2 processes competing
> > pipe, rather than only unixbench?
>
> What real applications have pipes with more than 1 writer & 1 reader?
> I'm OK with slowing down the weird cases if the common cases go faster.
From commit 0ddad21d3e99c743a3aa473121dc5561679e26bb:
While this isn't a common occurrence in the traditional "use a pipe as a
data transport" case, where you typically only have a single reader and
a single writer process, there is one common special case: using a pipe
as a source of "locking tokens" rather than for data communication.
In particular, the GNU make jobserver code ends up using a pipe as a way
to limit parallelism, where each job consumes a token by reading a byte
from the jobserver pipe, and releases the token by writing a byte back
to the pipe.
next prev parent reply other threads:[~2023-01-16 21:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-07 1:23 [PATCH v3] pipe: use __pipe_{lock,unlock} instead of spinlock Hongchen Zhang
2023-01-13 3:19 ` Hongchen Zhang
2023-01-13 9:32 ` Sedat Dilek
2023-01-16 1:52 ` Sedat Dilek
2023-01-16 2:16 ` Hongchen Zhang
2023-01-16 2:42 ` Sedat Dilek
2023-01-16 3:16 ` maobibo
2023-01-16 4:38 ` Matthew Wilcox
2023-01-16 21:10 ` Al Viro [this message]
2023-01-16 22:16 ` Andrew Morton
2023-01-17 6:54 ` Sedat Dilek
2023-01-29 2:29 ` Hongchen Zhang
-- strict thread matches above, loose matches on Subject: below --
2023-01-06 9:48 Hongchen Zhang
2023-01-06 19:13 ` Luis Chamberlain
2023-01-06 20:33 ` Sedat Dilek
2023-01-07 3:31 ` Hongchen Zhang
2023-01-07 0:58 ` Hongchen Zhang
2023-01-06 9:28 Hongchen Zhang
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=Y8W9TR5ifZmRADLB@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=christophe.jaillet@wanadoo.fr \
--cc=dhowells@redhat.com \
--cc=edumazet@google.com \
--cc=fmdefrancesco@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maobibo@loongson.cn \
--cc=mcgrof@kernel.org \
--cc=mchehab@kernel.org \
--cc=sedat.dilek@gmail.com \
--cc=willy@infradead.org \
--cc=zhanghongchen@loongson.cn \
/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.