lkml.org 
[lkml]   [2022]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2] minmax: clamp more efficiently by avoiding extra comparison
    On Fri, Sep 23, 2022 at 03:54:12PM -0700, Andrew Morton wrote:
    > On Fri, 23 Sep 2022 17:40:01 +0200 "Jason A. Donenfeld" <Jason@zx2c4.com> wrote:
    >
    > > Currently the clamp algorithm does:
    > >
    > > if (val > hi)
    > > val = hi;
    > > if (val < lo)
    > > val = lo;
    > >
    > > But since hi > lo by definition, this can be made more efficient with:
    > >
    > > if (val > hi)
    > > val = hi;
    > > else if (val < lo)
    > > val = lo;
    > >
    > > So fix up the clamp and clamp_t functions to do this, adding the same
    > > argument checking as for min and min_t.
    > >
    >
    > The patch adds 140 bytes of text to mm/memblock.o, for example.
    > Presumably from the additional branch. Larger text means larger cache
    > footprint means slower.

    Oh, interesting. I had spot-checked one clamp-using function (update_cfs_group)
    and it produced the same output just with some register swapping and other
    ordering changes. Hmm.

    But yes, text is bigger, but bss is smaller. This are my allmodconfig builds:

    text data bss dec hex filename
    43779952 59510881 28684428 131975261 7ddc85d vmlinux.before
    43781295 59510889 28676236 131968420 7ddada4 vmlinux

    > So where's the proof that this change gives us a more efficient kernel?

    A reasonable question. :)

    --
    Kees Cook

    \
     
     \ /
      Last update: 2022-09-24 02:02    [W:5.159 / U:0.592 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site