linux-kernel - Parallel compilation performance regression

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-next>] [day] [month] [year] [list]

Message-ID: <a1bafab884bb60250840a8721b78f4b5d3a6c2ed.camel@intel.com>
Date:   Thu, 18 Jun 2020 23:52:55 +0000
From:   "Derrick, Jonathan" <jonathan.derrick@...el.com>
To:     "dhowells@...hat.com" <dhowells@...hat.com>
CC:     "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Parallel compilation performance regression

Hi David,

I've been experiencing a performance regression when running a parallel
compilation (eg, make -j72) on recent kernels.

I bisected it to this commit:

commit b667b867344301e24f21d4a4c844675ff61d89e1
Author: David Howells <dhowells@...hat.com>
Date:   Tue Sep 24 16:09:04 2019 +0100

    pipe: Advance tail pointer inside of wait spinlock in pipe_read()

    Advance the pipe ring tail pointer inside of wait spinlock in pipe_read()
    so that the pipe can be written into with kernel notifications from
    contexts where pipe->mutex cannot be taken.

Prior to this commit I got 70% or so thread saturation of cc1 and after
it rarely gets above 15% and would often drop down to 1-2 threads. It
doesn't look like a clean revert either. Looking at upstream, it seems
that some later code changed the wakeup. I'm not really sure how this
all fits into parallelized make.

Best
Jon