linux-kernel - Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due to a kernel NULL pointer dereference)

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: <55F708D3.9090007@gmail.com>
Date:	Mon, 14 Sep 2015 13:50:11 -0400
From:	Austin S Hemmelgarn <ahferroin7@...il.com>
To:	sedat.dilek@...il.com, Peter Zijlstra <peterz@...radead.org>
Cc:	Baoquan He <bhe@...hat.com>, Denys Vlasenko <dvlasenk@...hat.com>,
	Tejun Heo <tj@...nel.org>, Christoph Lameter <cl@...ux.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Rientjes <rientjes@...gle.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Thomas Graf <tgraf@...g.ch>, Ingo Molnar <mingo@...nel.org>,
	the arch/x86 maintainers <x86@...nel.org>
Subject: Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due
 to a kernel NULL pointer dereference)

On 2015-09-14 03:49, Sedat Dilek wrote:
> On Mon, Sep 14, 2015 at 9:12 AM, Peter Zijlstra <peterz@...radead.org> wrote:
>> On Sun, Sep 13, 2015 at 04:33:39AM +0200, Sedat Dilek wrote:
>>>> It looks like an inline-optimization bug in CLANG when the compiler's
>>>> optimization-level is higher than -O2.
>>
>>>> [1] http://lists.linuxfoundation.org/pipermail/llvmlinux/2015-September/001355.html
>>>
>>> After some discussion on #llvm it turned out to be a known issue in LLVMLinux!
>>>
>>> Unfortunately, an existing patch [1] got archived which is still
>>> required to build x86_64 correctly.
>>
>>> [1] http://git.linuxfoundation.org/?p=llvmlinux.git;a=blob_plain;f=arch/x86_64/patches/ARCHIVE/0029-Fix-ARCH_HWEIGHT-for-compilation-with-clang.patch;hb=HEAD
>>
>> As long as LLVM cannot do things like that and requires full function
>> calls I cannot see it being a sensible compiler to use from a
>> performance POV.
>>
>> There's a fairly large difference between an inline POPCNT instruction
>> and a full out-of-line function call.
>>
>> /me goes back to ignoring LLVM for the time being.
>
> Can you give an example or describe a test-case to check the performance?
>
> I have here diverse Linux v4.2 kernels (all have the same kernel-config)...
>
> [ llvmlinux-patched ]
>
> #1: Compiled with CLANG v3.7 from a self-built llvm-toolchain v3.7.0
> #2: Compiled with GCC v4.9
>
> [ unpatched ]
>
> #3: Compiled with GCC v4.9
>
> Can you also comment on the effects of CONFIG_CC_OPTIMIZE_FOR_SIZE in
> case of performance?
> It is only to reduce binary size or does it also do some "speed" optimization?

I can comment at least a little about the -Os aspect (although not I'm 
no expert on this in particular).  In general, for _most_ use cases, a 
kernel compiled with CONFIG_CC_OPTIMIZE_FOR_SIZE will run slower than 
one compiled without it.  On rare occasion though, it may actually run 
faster, the only cases I've seen where this happens are specialized uses 
that are very memory pressure dependent and run almost entirely in 
userspace with almost no syscalls (for example math related stuff 
operating on _very, very big_ (as in, >1 trillion elements) 
multidimensional matrices, with complex memory constraints), and even 
then it's usually a miniscule improvement in performance (generally less 
than 1%, which can of course be significant depending on how long it 
takes before the improvement).


Download attachment "smime.p7s" of type "application/pkcs7-signature" (3019 bytes)