From: Linus Torvalds <firstname.lastname@example.org>
To: Vincent Guittot <email@example.com>, DJ Delorie <firstname.lastname@example.org>
Cc: David Sterba <email@example.com>,
David Howells <firstname.lastname@example.org>,
Eric Biggers <email@example.com>,
Al Viro <firstname.lastname@example.org>,
Linux Kernel Mailing List <email@example.com>,
Peter Zijlstra <firstname.lastname@example.org>,
Ingo Molnar <email@example.com>
Subject: Re: [PATCH 0/2] pipe: Fixes [ver #2]
Date: Mon, 9 Dec 2019 09:48:27 -0800 [thread overview]
Message-ID: <CAHk-=wicgTacrHUJmSBbW9MYAdMPdrXzULPNqQ3G7+HkLeNf1Q@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 3222 bytes --]
[ Added DJ to the participants, since he seems to be the Fedora make
maintainer - DJ, any chance that this absolutely horrid 'make' buf can
be fixed in older versions too, not just rawhide? The bugfix is two
and a half years old by now, and the bug looks real and very serious ]
On Mon, Dec 9, 2019 at 1:54 AM Vincent Guittot
> Which version of make should I use to reproduce the problem ?
So the problematic one is "make-4.2.1-13.fc30.x86_64" in Fedora 30.
I'm assuming it's fairly plain 4.2.1, but I didn't try to look into
the source rpm or anything like that.
The working one for me was just the top of -git from
which is 4.2.92 right now.
The fix is presumably commit b552b05 ("[SV 51159] Use a non-blocking
read with pselect to avoid hangs") as per Akemi. That is indeed after
4.2.1, and it looks real.
Before that commit the buggy jobserver code basically does
(1) use pselect() to wait for readable and see child deaths atomically
(2) use blocking read to get the token
and while (1) is atomic, if the child death happens between the two,
it goes into the blocking read and has SIGCHLD blocked, so it will try
to read the token from the token pipe, but it will never react to the
child death - and the child death is what is going to _release_ a
So what seems to happen is that when the right timing triggers, you
end up with a lot of sub-makes waiting for a token, but they are also
all supposed to _release_ a token. So you don't have enough tokens to
go around. In the worst case, _everybody_ who has a token is also not
releasing it, and then you end up triggering the timeout code (after
one second), which will make things really go into a crawl.
And by a crawl I mean that worst-case you really end up with just one
job per second per sub-make. It will take _hours_ to compile the
kernel at that speed, when it normally finishes in 15 minutes on my
machine even when I do a from-scratch allmodconfig build.
It does seem to be a major bug in the jobserver code. In particular
with the trial fair and exclusive wakeup patch that I sent out in the
other thread, it seems to be _reliably_ much worse and triggers 100%
of the time for me.
It's possible that my trial patch is buggy, but everything else looks
fine, and with a fixed make the trial patch works for me.
I'll include the trial patch here too, I think I cc'd you on the other
thread too, but hey..
Anyway, it looks like the sync wakeup thing is more of a "get timing
right by luck" thing than anything else. Possibly it actually causes
the reverse order of reader wakeups more often (ie the most _recent_
reader is most likely to get woken up synchronously) and that may be
what really ends up masking the jobserver problem, since apparently
doing wakeups in the fair and proper order makes things much worse..
What a horrible pain that pipe rework ended up being. But I think
we're in better shape now than we used to be, it just had very
unfortunate timing issues and several real bugs.
But sadly, there's no way I can push that fair pipe wakeup thing as
long as this horribly buggy version of make is widespread.
[-- Attachment #2: patch.diff --]
[-- Type: application/x-patch, Size: 9612 bytes --]
next prev parent reply other threads:[~2019-12-09 17:49 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-05 22:30 [PATCH 0/2] pipe: Fixes [ver #2] David Howells
2019-12-05 22:30 ` [PATCH 1/2] pipe: Remove assertion from pipe_poll() " David Howells
2019-12-05 22:30 ` [PATCH 2/2] pipe: Fix missing mask update after pipe_wait() " David Howells
2019-12-05 23:58 ` Linus Torvalds
2019-12-06 13:56 ` [PATCH 0/2] pipe: Fixes " David Sterba
2019-12-06 17:09 ` Linus Torvalds
2019-12-06 17:42 ` Linus Torvalds
2019-12-06 18:59 ` Linus Torvalds
2019-12-07 21:31 ` Akemi Yagi
2019-12-08 16:45 ` Akemi Yagi
2019-12-08 18:04 ` Linus Torvalds
2019-12-09 3:07 ` Linus Torvalds
2019-12-06 20:28 ` Linus Torvalds
2019-12-06 21:04 ` Linus Torvalds
2019-12-07 3:50 ` Linus Torvalds
2019-12-07 4:01 ` Linus Torvalds
2019-12-07 22:47 ` Linus Torvalds
2019-12-09 9:53 ` Vincent Guittot
2019-12-09 17:48 ` Linus Torvalds [this message]
2019-12-09 17:57 ` Akemi Yagi
2019-12-09 18:18 ` Linus Torvalds
2019-12-09 18:24 ` Linus Torvalds
2019-12-18 20:59 ` Josh Triplett
2019-12-10 2:58 ` DJ Delorie
2019-12-10 14:38 ` Vincent Guittot
2019-12-10 17:39 ` Linus Torvalds
2019-12-11 18:09 ` DJ Delorie
2019-12-11 18:59 ` Linus Torvalds
2019-12-12 10:18 ` Konstantin Khlebnikov
2019-12-18 22:51 ` Linus Torvalds
2019-12-19 0:03 ` Josh Triplett
2019-12-19 0:14 ` Josh Triplett
2019-12-19 0:51 ` Linus Torvalds
2019-12-19 0:54 ` Linus Torvalds
2019-12-19 7:56 ` David Howells
2019-12-19 16:35 ` Linus Torvalds
2019-12-11 20:55 ` David Howells
2019-12-12 1:28 ` Linus Torvalds
2019-12-12 7:34 ` David Howells
2019-12-09 14:55 ` David Sterba
2019-12-06 21:26 ` David Howells
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).