linux-kernel - Re: [PATCH V2] kmalloc_index optimization(code size & runtime stable)

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: <339dbb54-b4bc-78e2-e3f0-986814e86d0e@suse.cz>
Date:   Tue, 21 Apr 2020 15:13:55 +0200
From:   Vlastimil Babka <vbabka@...e.cz>
To:     1587089010-110083-1-git-send-email-bernard@...o.com,
        Christoph Lameter <cl@...ux.com>,
        Pekka Enberg <penberg@...nel.org>,
        David Rientjes <rientjes@...gle.com>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Cc:     opensource.kernel@...o.com, Bernard Zhao <bernard@...o.com>
Subject: Re: [PATCH V2] kmalloc_index optimization(code size & runtime stable)

On 4/21/20 5:25 AM, Bernard Zhao wrote:
> kmalloc_index inline function code size optimization and runtime
> performance stability optimization. After optimization, the function
> kmalloc_index is more stable, the size will never affecte the function`s
> execution efficiency.
> And follow test data shows that the performance of new optimization
> exceeds the original algorithm when applying for more than 512 Bytes
> (include 512B).And new optimization runtime is more stable than before.
> Test platform:install vmware ubuntu 16.04, ram 2G, cpu 1, i5-8500 3.00GHz
> Compiler: gcc -O2 optimization, gcc version 5.4.0.
> Just test diff code part.
> Follow is detailed test data:
>             size        time/Per 100 million times
>                         old fun		new fun with optimise
> 		8	203777		241934
> 		16	245611		409278
> 		32	236384		408419
> 		64	275499		447732
> 		128	354909		416439
> 		256	360472		406598
> 		512	431072		409168
> 		1024	463822		407401
>         2 * 1024	548519		407710
>         4 * 1024	623378		422326
>         8 * 1024	655932		407457
>        16 * 1024	744673		417574
>        32 * 1024	824889		415316
>        64 * 1024	854374		408577
>       128 * 1024	968079		433582
>       256 * 1024	985527		412080
>       512 * 1024	1196877		448199
>      1024 * 1024	1310315		448969
> 2  * 1024 * 1024	1367441		513117
> 4  * 1024 * 1024	1264623		415019
> 8  * 1024 * 1024	1255727		417197
> 16 * 1024 * 1024	1401431		411087
> 32 * 1024 * 1024	1440415		416616
> 64 * 1024 * 1024	1428122		417459

No, the kernel will never see these time improvements (or non-improvements for
small sizes). See how kmalloc() and kmalloc_node() both call kmalloc_index()
only under "if (__builtin_constant_p(size))"
which means kmalloc is called with a (compile-time) constant size, so this code
is only evaluated at compile time, not while kernel is running. Otherwise it
really wouldn't be implemented as a stream of if's :)
The cases that are not compile time constant size end up in kmalloc_slab(), so
you can see how that one is implemented and what its performance is.