linux-kernel - Re: [PATCH] mm: page_alloc: High-order per-cpu page allocator v7

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: <20161207194801.krhonj7yggbedpba@techsingularity.net>
Date:   Wed, 7 Dec 2016 19:48:01 +0000
From:   Mel Gorman <mgorman@...hsingularity.net>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Christoph Lameter <cl@...ux.com>,
        Michal Hocko <mhocko@...e.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Johannes Weiner <hannes@...xchg.org>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        Linux-MM <linux-mm@...ck.org>,
        Linux-Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm: page_alloc: High-order per-cpu page allocator v7

On Wed, Dec 07, 2016 at 11:00:49AM -0800, Eric Dumazet wrote:
> On Wed, 2016-12-07 at 10:12 +0000, Mel Gorman wrote:
> 
> > This is the result from netperf running UDP_STREAM on localhost. It was
> > selected on the basis that it is slab-intensive and has been the subject
> > of previous SLAB vs SLUB comparisons with the caveat that this is not
> > testing between two physical hosts.
> > 
> 
> Interesting results.
> 
> netperf UDP_STREAM is not really slab intensive : (for large sendsizes
> like 16KB)
> 

Interesting because it didn't match what I previous measured but then
again, when I established that netperf on localhost was slab intensive,
it was also an older kernel. Can you tell me if SLAB or SLUB was enabled
in your test kernel?

Either that or the baseline I used has since been changed from what you
are testing and we're not hitting the same paths.

> Bulk of the storage should be allocated from alloc_skb_with_frags(),
> ie using pages.
> 
> And I am not sure we enabled high order pages in this path ?
> 
> ip_make_skb()
>  __ip_append_data()
>   sock_alloc_send_skb()
>    sock_alloc_send_pskb (...,  max_page_order=0)
>     alloc_skb_with_frags ( max_page_order=0)
>  

It doesn't look like it. While it's not directly related to this patch,
can you give the full stack? I'm particularly curious to see if these
allocations are in an IRQ path or not.

> We probably could enable high-order pages there, if we believe this is
> okay.
> 

Ultimately, not a great idea unless you want variable performance depending
on whether high-order pages are available or not. The motivation for the
patch was primarily for SLUB-intensive workloads.

-- 
Mel Gorman
SUSE Labs