[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=whdiabQ0dqVDJ0_5dfur7f2D5oESCjv34f4svrK3RJj=w@mail.gmail.com>
Date: Wed, 12 Feb 2020 12:03:26 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Josh Triplett <josh@...htriplett.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Applying pipe fix this merge window?
On Sat, Feb 8, 2020 at 12:36 AM Josh Triplett <josh@...htriplett.org> wrote:
>
> I've been hammering on your pipe fix patch (switching to exclusive wait
> queues) for a month or so, on several different systems, and I've run
> into no issues with it. The patch *substantially* improves parallel
> build times on large (~100 CPU) systems, both with parallel make and
> with other things that use make's pipe-based jobserver.
Hmm. I just applied the doc fix that Randy sent, and that made me
revisit this commit and the commit message.
And I realized that I find it surprising that it makes your build
times noticeably better.
Yes, I have that silly example program to show the issue in the commit
message, and yes, the exclusive directed write->read wakeups should
most definitely improve by that commit.
But the make jobserver code ends up using "poll()/pselect()" and
non-blocking reads, because of how it handles the child death signals.
Which means that none of the nice exclusive directed write->read
wakeups should even trigger in the first place, because the readers
never block, and he poll/pselect code doesn't use exclusive wakeups
(because it can't - it doesn't actually consume the data).
So I was looking at it, and going "it should actually not help GNU
jobserver at all" in the fixed jobserver case.
So humor me, Josh - can you try to figure out why your numbers changed
for this commit?
Linus
Powered by blists - more mailing lists