linux-kernel - Re: [PATCH 3/4] mm, page_allocator: Only use per-cpu allocator for irq-safe requests

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: <20170112104732.jjdjbjrg7uqczttc@techsingularity.net>
Date:   Thu, 12 Jan 2017 10:47:32 +0000
From:   Mel Gorman <mgorman@...hsingularity.net>
To:     Jesper Dangaard Brouer <brouer@...hat.com>
Cc:     Linux Kernel <linux-kernel@...r.kernel.org>,
        Linux-MM <linux-mm@...ck.org>,
        Hillf Danton <hillf.zj@...baba-inc.com>
Subject: Re: [PATCH 3/4] mm, page_allocator: Only use per-cpu allocator for
 irq-safe requests

On Wed, Jan 11, 2017 at 02:27:12PM +0100, Jesper Dangaard Brouer wrote:
> On Wed, 11 Jan 2017 13:44:20 +0100
> Jesper Dangaard Brouer <brouer@...hat.com> wrote:
> 
> > On Mon,  9 Jan 2017 16:35:17 +0000 Mel Gorman <mgorman@...hsingularity.net> wrote:
> >  
> > > The following is results from a page allocator micro-benchmark. Only
> > > order-0 is interesting as higher orders do not use the per-cpu allocator  
> > 
> > Micro-benchmarked with [1] page_bench02:
> >  modprobe page_bench02 page_order=0 run_flags=$((2#010)) loops=$((10**8)); \
> >   rmmod page_bench02 ; dmesg --notime | tail -n 4
> > 
> > Compared to baseline: 213 cycles(tsc) 53.417 ns
> >  - against this     : 184 cycles(tsc) 46.056 ns
> >  - Saving           : -29 cycles
> >  - Very close to expected 27 cycles saving [see below [2]]
> 
> When perf benchmarking I noticed that the "summed" children perf
> overhead from calling alloc_pages_current() is 65.05%. Compared to
> "free-path" of summed 28.28% of calls "under" __free_pages().
> 
> This is caused by CONFIG_NUMA=y, as call path is long with NUMA
> (and other helpers are also non-inlined calls):
> 
>  alloc_pages
>   -> alloc_pages_current
>       -> __alloc_pages_nodemask
>           -> get_page_from_freelist
> 
> Without NUMA the call levels gets compacted by inlining to:
> 
>  __alloc_pages_nodemask
>   -> get_page_from_freelist
> 
> After disabling NUMA, the split between alloc(48.80%) vs. free(42.67%)
> side is more balanced.
> 
> Saving by disabling CONFIG_NUMA of:
>  - CONFIG_NUMA=y : 184 cycles(tsc) 46.056 ns
>  - CONFIG_NUMA=n : 143 cycles(tsc) 35.913 ns
>  - Saving:       :  41 cycles (approx 22%)
> 
> I would conclude, there is room for improvements with CONFIG_NUMA code
> path case. Lets followup on that in a later patch series...
> 

Potentially. The NUMA paths do memory policy work and has more
complexity in the statistics path. It may be possible to side-step some
of it. There were not many safe options when I last looked but that was
a long time ago. Most of the focus has been on the core allocator
itself and not the wrappers around it.

-- 
Mel Gorman
SUSE Labs