lkml.org 
[lkml]   [2017]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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@redhat.com> wrote:
    >
    > > On Mon, 9 Jan 2017 16:35:17 +0000 Mel Gorman <mgorman@techsingularity.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

    \
     
     \ /
      Last update: 2017-01-12 11:48    [W:0.024 / U:0.404 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site