lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ