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

[Mel Gorman <mgorman@techsingularity.net>]

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