lkml.org 
[lkml]   [2015]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due to a kernel NULL pointer dereference)
    From
    Date
    On 2015-09-14 03:49, Sedat Dilek wrote:
    > On Mon, Sep 14, 2015 at 9:12 AM, Peter Zijlstra <peterz@infradead.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).

    [unhandled content-type:application/pkcs7-signature]
    \
     
     \ /
      Last update: 2015-09-14 20:01    [W:2.259 / U:0.344 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site