On Mon, 16 Jan 2023 21:10:37 +0000 Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > 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. The author has tested this patch with Linus's test code from 0ddad21d3e and the results were OK (https://lkml.kernel.org/r/c3cbede6-f19e-3333-ba0f-d3f005e5d599@xxxxxxxxxxx). I've been stalling on this patch until Linus gets back to his desk, which now appears to have happened. Hongchen, when convenient, please capture this discussion (as well as the testing results with Linus's sample code) in the changelog and send us a v4, with Linus on cc?
