lkml.org 
[lkml]   [2020]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH -tip] compiler_types.h: Optimize __unqual_scalar_typeof compilation time
    On Wed, May 27, 2020 at 3:30 PM Marco Elver <elver@google.com> wrote:
    >
    > On Wed, 27 May 2020 at 15:11, Sedat Dilek <sedat.dilek@gmail.com> wrote:
    > >
    > > On Wed, May 27, 2020 at 2:50 PM Arnd Bergmann <arnd@arndb.de> wrote:
    > > >
    > > > On Wed, May 27, 2020 at 2:35 PM Sedat Dilek <sedat.dilek@gmail.com> wrote:
    > > > > On Wed, May 27, 2020 at 2:31 PM Arnd Bergmann <arnd@arndb.de> wrote:
    > > > > > On Wed, May 27, 2020 at 1:36 PM Sedat Dilek <sedat.dilek@gmail.com> wrote:
    > > > > > > On Wed, May 27, 2020 at 1:27 PM Arnd Bergmann <arnd@arndb.de> wrote:
    > > > > > > > On Wed, May 27, 2020 at 12:33 PM Marco Elver <elver@google.com> wrote:
    > > > > > > >
    > > > > > > > This gives us back 80% of the performance drop on clang, and 50%
    > > > > > > > of the drop I saw with gcc, compared to current mainline.
    > > > > > > >
    > > > > > > > Tested-by: Arnd Bergmann <arnd@arndb.de>
    > > > > > > >
    > > > > > >
    > > > > > > Hi Arnd,
    > > > > > >
    > > > > > > with "mainline" you mean Linux-next aka Linux v5.8 - not v5.7?
    > > > > >
    > > > > > I meant v5.7.
    > > > > >
    > > > > > > I have not seen __unqual_scalar_typeof(x) in compiler_types.h in Linux v5.7.
    > > > > > >
    > > > > > > Is there a speedup benefit also for Linux v5.7?
    > > > > > > Which patches do I need?
    > > > > >
    > > > > > v5.7-rc is the baseline and is the fastest I currently see. On certain files,
    > > > > > I saw an intermittent 10x slowdown that was already fixed earlier, now
    > > > > > linux-next
    > > > > > is more like 2x slowdown for me and 1.2x with this patch on top, so we're
    > > > > > almost back to the speed of linux-5.7.
    > > > > >
    > > > >
    > > > > Which clang version did you use - and have you set KCSAN kconfigs -
    > > > > AFAICS this needs clang-11?
    > > >
    > > > I'm currently using clang-11, but I see the same problem with older
    > > > versions, and both with and without KCSAN enabled. I think the issue
    > > > is mostly the deep nesting of macros that leads to code bloat.
    > > >
    > >
    > > Thanks.
    > >
    > > With clang-10:
    > >
    > > $ scripts/diffconfig /boot/config-5.7.0-rc7-2-amd64-clang .config
    > > BUILD_SALT "5.7.0-rc7-2-amd64-clang" -> "5.7.0-rc7-3-amd64-clang"
    > > +HAVE_ARCH_KCSAN y
    >
    > Clang 10 doesn't support KCSAN (HAVE_KCSAN_COMPILER unset).
    >
    > > With clang-11:
    > >
    > > $ scripts/diffconfig /boot/config-5.7.0-rc7-2-amd64-clang .config
    > > BUILD_SALT "5.7.0-rc7-2-amd64-clang" -> "5.7.0-rc7-3-amd64-clang"
    > > CLANG_VERSION 100001 -> 110000
    > > +CC_HAS_ASM_INLINE y
    > > +HAVE_ARCH_KCSAN y
    > > +HAVE_KCSAN_COMPILER y
    > > +KCSAN n
    > >
    > > Which KCSAN kconfigs did you enable?
    >
    > To clarify: as said in [1], KCSAN (or any other instrumentation) is no
    > longer relevant to the issue here, and the compile-time regression is
    > observable with most configs. The problem is due to pre-processing and
    > parsing, which came about due to new READ_ONCE() and the
    > __unqual_scalar_typeof() macro (which this patch optimizes).
    >
    > KCSAN and new ONCEs got tangled up because we first attempted to
    > annotate {READ,WRITE}_ONCE() with data_race(), but that turned out to
    > have all kinds of other issues (explanation in [2]). So we decided to
    > drop all the KCSAN-specific bits from ONCE, and require KCSAN to be
    > Clang 11. Those fixes were applied to the first version of new
    > {READ,WRITE}_ONCE() in -tip, which actually restored the new ONCEs to
    > the pre-KCSAN version (now that KCSAN can deal with them without
    > annotations).
    >
    > Hope this makes more sense now.
    >
    > [1] https://lore.kernel.org/lkml/CANpmjNOUdr2UG3F45=JaDa0zLwJ5ukPc1MMKujQtmYSmQnjcXg@mail.gmail.com/
    > [2] https://lore.kernel.org/lkml/20200521142047.169334-1-elver@google.com/
    >

    Thanks, Marco.

    I pulled tip.git#locking/kcsan on top of Linux v5.7-rc7 and applied this patch.
    Just wanted to try KCSAN for the first time and it will also be my
    first building with clang-11.
    That's why I asked.

    - Sedat -

    \
     
     \ /
      Last update: 2020-05-27 15:38    [W:4.585 / U:0.588 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site