All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Josh Triplett <josh@joshtriplett.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Applying pipe fix this merge window?
Date: Wed, 12 Feb 2020 12:03:26 -0800	[thread overview]
Message-ID: <CAHk-=whdiabQ0dqVDJ0_5dfur7f2D5oESCjv34f4svrK3RJj=w@mail.gmail.com> (raw)
In-Reply-To: <20200208083604.GA86051@localhost>

On Sat, Feb 8, 2020 at 12:36 AM Josh Triplett <josh@joshtriplett.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

  parent reply	other threads:[~2020-02-12 20:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-08  8:36 Applying pipe fix this merge window? Josh Triplett
2020-02-08 18:45 ` Linus Torvalds
2020-02-08 21:53   ` Linus Torvalds
2020-02-08 22:04     ` Josh Triplett
2020-02-12 20:03 ` Linus Torvalds [this message]
2020-02-14  6:08   ` Josh Triplett

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-=whdiabQ0dqVDJ0_5dfur7f2D5oESCjv34f4svrK3RJj=w@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.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 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.