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:0.113 / U:1.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site