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

2016-12-02 Thread Paolo Abeni
On Fri, 2016-12-02 at 16:37 +0100, Jesper Dangaard Brouer wrote: > On Thu, 01 Dec 2016 23:17:48 +0100 > Paolo Abeni wrote: > > > On Thu, 2016-12-01 at 18:34 +0100, Jesper Dangaard Brouer wrote: > > > (Cc. netdev, we might have an issue with Paolo's UDP accounting and > > >

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

2016-12-02 Thread Paolo Abeni
On Fri, 2016-12-02 at 16:37 +0100, Jesper Dangaard Brouer wrote: > On Thu, 01 Dec 2016 23:17:48 +0100 > Paolo Abeni wrote: > > > On Thu, 2016-12-01 at 18:34 +0100, Jesper Dangaard Brouer wrote: > > > (Cc. netdev, we might have an issue with Paolo's UDP accounting and > > > small socket queues) >

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

2016-12-02 Thread Jesper Dangaard Brouer
On Thu, 01 Dec 2016 23:17:48 +0100 Paolo Abeni wrote: > On Thu, 2016-12-01 at 18:34 +0100, Jesper Dangaard Brouer wrote: > > (Cc. netdev, we might have an issue with Paolo's UDP accounting and > > small socket queues) > > > > On Wed, 30 Nov 2016 16:35:20 + > > Mel Gorman

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

2016-12-02 Thread Jesper Dangaard Brouer
On Thu, 01 Dec 2016 23:17:48 +0100 Paolo Abeni wrote: > On Thu, 2016-12-01 at 18:34 +0100, Jesper Dangaard Brouer wrote: > > (Cc. netdev, we might have an issue with Paolo's UDP accounting and > > small socket queues) > > > > On Wed, 30 Nov 2016 16:35:20 + > > Mel Gorman wrote: > > > >

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

2016-12-01 Thread Paolo Abeni
On Thu, 2016-12-01 at 18:34 +0100, Jesper Dangaard Brouer wrote: > (Cc. netdev, we might have an issue with Paolo's UDP accounting and > small socket queues) > > On Wed, 30 Nov 2016 16:35:20 + > Mel Gorman wrote: > > > > I don't quite get why you are setting the

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

2016-12-01 Thread Paolo Abeni
On Thu, 2016-12-01 at 18:34 +0100, Jesper Dangaard Brouer wrote: > (Cc. netdev, we might have an issue with Paolo's UDP accounting and > small socket queues) > > On Wed, 30 Nov 2016 16:35:20 + > Mel Gorman wrote: > > > > I don't quite get why you are setting the socket recv size > > > (with

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

2016-12-01 Thread Jesper Dangaard Brouer
(Cc. netdev, we might have an issue with Paolo's UDP accounting and small socket queues) On Wed, 30 Nov 2016 16:35:20 + Mel Gorman wrote: > > I don't quite get why you are setting the socket recv size > > (with -- -s and -S) to such a small number, size + 256. >

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

2016-12-01 Thread Jesper Dangaard Brouer
(Cc. netdev, we might have an issue with Paolo's UDP accounting and small socket queues) On Wed, 30 Nov 2016 16:35:20 + Mel Gorman wrote: > > I don't quite get why you are setting the socket recv size > > (with -- -s and -S) to such a small number, size + 256. > > > > Maybe I missed

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

2016-11-30 Thread Mel Gorman
On Wed, Nov 30, 2016 at 04:06:12PM +0100, Jesper Dangaard Brouer 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

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

2016-11-30 Thread Mel Gorman
On Wed, Nov 30, 2016 at 04:06:12PM +0100, Jesper Dangaard Brouer 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

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

2016-11-30 Thread Jesper Dangaard Brouer
On Wed, 30 Nov 2016 14:06:15 + Mel Gorman wrote: > On Wed, Nov 30, 2016 at 01:40:34PM +0100, Jesper Dangaard Brouer wrote: > > > > On Sun, 27 Nov 2016 13:19:54 + Mel Gorman > > wrote: > > > > [...] > > > SLUB has been the

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

2016-11-30 Thread Jesper Dangaard Brouer
On Wed, 30 Nov 2016 14:06:15 + Mel Gorman wrote: > On Wed, Nov 30, 2016 at 01:40:34PM +0100, Jesper Dangaard Brouer wrote: > > > > On Sun, 27 Nov 2016 13:19:54 + Mel Gorman > > wrote: > > > > [...] > > > SLUB has been the default small kernel object allocator for quite some > > >

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

2016-11-30 Thread Michal Hocko
On Wed 30-11-16 14:16:13, Mel Gorman wrote: > On Wed, Nov 30, 2016 at 02:05:50PM +0100, Michal Hocko wrote: [...] > > But... Unless I am missing something this effectively means that we do > > not exercise high order atomic reserves. Shouldn't we fallback to > > the locked

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

2016-11-30 Thread Michal Hocko
On Wed 30-11-16 14:16:13, Mel Gorman wrote: > On Wed, Nov 30, 2016 at 02:05:50PM +0100, Michal Hocko wrote: [...] > > But... Unless I am missing something this effectively means that we do > > not exercise high order atomic reserves. Shouldn't we fallback to > > the locked

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

2016-11-30 Thread Mel Gorman
On Wed, Nov 30, 2016 at 02:05:50PM +0100, Michal Hocko wrote: > On Sun 27-11-16 13:19:54, Mel Gorman wrote: > [...] > > @@ -2588,18 +2594,22 @@ struct page *buffered_rmqueue(struct zone > > *preferred_zone, > > struct page *page; > > bool cold = ((gfp_flags & __GFP_COLD) != 0); > > > >

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

2016-11-30 Thread Mel Gorman
On Wed, Nov 30, 2016 at 02:05:50PM +0100, Michal Hocko wrote: > On Sun 27-11-16 13:19:54, Mel Gorman wrote: > [...] > > @@ -2588,18 +2594,22 @@ struct page *buffered_rmqueue(struct zone > > *preferred_zone, > > struct page *page; > > bool cold = ((gfp_flags & __GFP_COLD) != 0); > > > >

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

2016-11-30 Thread Mel Gorman
On Wed, Nov 30, 2016 at 01:40:34PM +0100, Jesper Dangaard Brouer wrote: > > On Sun, 27 Nov 2016 13:19:54 + Mel Gorman > wrote: > > [...] > > SLUB has been the default small kernel object allocator for quite some time > > but it is not universally used due to

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

2016-11-30 Thread Mel Gorman
On Wed, Nov 30, 2016 at 01:40:34PM +0100, Jesper Dangaard Brouer wrote: > > On Sun, 27 Nov 2016 13:19:54 + Mel Gorman > wrote: > > [...] > > SLUB has been the default small kernel object allocator for quite some time > > but it is not universally used due to performance concerns and a

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

2016-11-30 Thread Michal Hocko
On Sun 27-11-16 13:19:54, Mel Gorman wrote: [...] > @@ -2588,18 +2594,22 @@ struct page *buffered_rmqueue(struct zone > *preferred_zone, > struct page *page; > bool cold = ((gfp_flags & __GFP_COLD) != 0); > > - if (likely(order == 0)) { > + if (likely(order <=

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

2016-11-30 Thread Michal Hocko
On Sun 27-11-16 13:19:54, Mel Gorman wrote: [...] > @@ -2588,18 +2594,22 @@ struct page *buffered_rmqueue(struct zone > *preferred_zone, > struct page *page; > bool cold = ((gfp_flags & __GFP_COLD) != 0); > > - if (likely(order == 0)) { > + if (likely(order <=

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

2016-11-30 Thread Jesper Dangaard Brouer
On Sun, 27 Nov 2016 13:19:54 + Mel Gorman wrote: [...] > SLUB has been the default small kernel object allocator for quite some time > but it is not universally used due to performance concerns and a reliance > on high-order pages. The high-order concerns has

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

2016-11-30 Thread Jesper Dangaard Brouer
On Sun, 27 Nov 2016 13:19:54 + Mel Gorman wrote: [...] > SLUB has been the default small kernel object allocator for quite some time > but it is not universally used due to performance concerns and a reliance > on high-order pages. The high-order concerns has two major components -- >

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

2016-11-30 Thread Mel Gorman
On Mon, Nov 28, 2016 at 12:00:41PM +0100, Vlastimil Babka wrote: > > 1-socket 6 year old machine > > 4.9.0-rc5 4.9.0-rc5 > > vanilla hopcpu-v3 > > Hmeansend-64 87.47 ( 0.00%) 127.14 (

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

2016-11-30 Thread Mel Gorman
On Mon, Nov 28, 2016 at 12:00:41PM +0100, Vlastimil Babka wrote: > > 1-socket 6 year old machine > > 4.9.0-rc5 4.9.0-rc5 > > vanilla hopcpu-v3 > > Hmeansend-64 87.47 ( 0.00%) 127.14 (

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

2016-11-28 Thread Vlastimil Babka
On 11/28/2016 07:54 PM, Christoph Lameter wrote: > On Mon, 28 Nov 2016, Mel Gorman wrote: > >> If you have a series aimed at parts of the fragmentation problem or how >> subsystems can avoid tracking 4K pages in some important cases then by >> all means post them. > > I designed SLUB with defrag

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

2016-11-28 Thread Vlastimil Babka
On 11/28/2016 07:54 PM, Christoph Lameter wrote: > On Mon, 28 Nov 2016, Mel Gorman wrote: > >> If you have a series aimed at parts of the fragmentation problem or how >> subsystems can avoid tracking 4K pages in some important cases then by >> all means post them. > > I designed SLUB with defrag

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

2016-11-28 Thread Johannes Weiner
On Sun, Nov 27, 2016 at 01:19:54PM +, Mel Gorman wrote: > While it is recognised that this is a mixed bag of results, the patch > helps a lot more workloads than it hurts and intuitively, avoiding the > zone->lock in some cases is a good thing. > > Signed-off-by: Mel Gorman

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

2016-11-28 Thread Johannes Weiner
On Sun, Nov 27, 2016 at 01:19:54PM +, Mel Gorman wrote: > While it is recognised that this is a mixed bag of results, the patch > helps a lot more workloads than it hurts and intuitively, avoiding the > zone->lock in some cases is a good thing. > > Signed-off-by: Mel Gorman This seems like

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

2016-11-28 Thread Christoph Lameter
On Mon, 28 Nov 2016, Mel Gorman wrote: > If you have a series aimed at parts of the fragmentation problem or how > subsystems can avoid tracking 4K pages in some important cases then by > all means post them. I designed SLUB with defrag methods in mind. We could warm up some old patchsets that

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

2016-11-28 Thread Christoph Lameter
On Mon, 28 Nov 2016, Mel Gorman wrote: > If you have a series aimed at parts of the fragmentation problem or how > subsystems can avoid tracking 4K pages in some important cases then by > all means post them. I designed SLUB with defrag methods in mind. We could warm up some old patchsets that

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

2016-11-28 Thread Mel Gorman
On Mon, Nov 28, 2016 at 10:38:58AM -0600, Christoph Lameter wrote: > > > that only insiders know how to tune and an overall fragile solution. > > While I agree with all of this, it's also a problem independent of this > > patch. > > It is related. The fundamental issue with fragmentation remain

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

2016-11-28 Thread Mel Gorman
On Mon, Nov 28, 2016 at 10:38:58AM -0600, Christoph Lameter wrote: > > > that only insiders know how to tune and an overall fragile solution. > > While I agree with all of this, it's also a problem independent of this > > patch. > > It is related. The fundamental issue with fragmentation remain

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

2016-11-28 Thread Christoph Lameter
On Mon, 28 Nov 2016, Mel Gorman wrote: > Yes, that's a problem for SLUB with or without this patch. It's always > been the case that SLUB relying on high-order pages for performance is > problematic. This is a general issue in the kernel. Performance often requires larger contiguous ranges of

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

2016-11-28 Thread Christoph Lameter
On Mon, 28 Nov 2016, Mel Gorman wrote: > Yes, that's a problem for SLUB with or without this patch. It's always > been the case that SLUB relying on high-order pages for performance is > problematic. This is a general issue in the kernel. Performance often requires larger contiguous ranges of

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

2016-11-28 Thread Mel Gorman
On Mon, Nov 28, 2016 at 09:39:19AM -0600, Christoph Lameter wrote: > On Sun, 27 Nov 2016, Mel Gorman wrote: > > > > > SLUB has been the default small kernel object allocator for quite some time > > but it is not universally used due to performance concerns and a reliance > > on high-order pages.

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

2016-11-28 Thread Mel Gorman
On Mon, Nov 28, 2016 at 09:39:19AM -0600, Christoph Lameter wrote: > On Sun, 27 Nov 2016, Mel Gorman wrote: > > > > > SLUB has been the default small kernel object allocator for quite some time > > but it is not universally used due to performance concerns and a reliance > > on high-order pages.

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

2016-11-28 Thread Christoph Lameter
On Sun, 27 Nov 2016, Mel Gorman wrote: > > SLUB has been the default small kernel object allocator for quite some time > but it is not universally used due to performance concerns and a reliance > on high-order pages. The high-order concerns has two major components -- > high-order pages are not

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

2016-11-28 Thread Christoph Lameter
On Sun, 27 Nov 2016, Mel Gorman wrote: > > SLUB has been the default small kernel object allocator for quite some time > but it is not universally used due to performance concerns and a reliance > on high-order pages. The high-order concerns has two major components -- > high-order pages are not

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

2016-11-28 Thread Mel Gorman
On Mon, Nov 28, 2016 at 12:00:41PM +0100, Vlastimil Babka wrote: > On 11/27/2016 02:19 PM, Mel Gorman wrote: > > > > 2-socket modern machine > > 4.9.0-rc5 4.9.0-rc5 > > vanilla hopcpu-v3 > > Hmeansend-64

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

2016-11-28 Thread Mel Gorman
On Mon, Nov 28, 2016 at 12:00:41PM +0100, Vlastimil Babka wrote: > On 11/27/2016 02:19 PM, Mel Gorman wrote: > > > > 2-socket modern machine > > 4.9.0-rc5 4.9.0-rc5 > > vanilla hopcpu-v3 > > Hmeansend-64

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

2016-11-28 Thread Vlastimil Babka
On 11/27/2016 02:19 PM, Mel Gorman wrote: 2-socket modern machine 4.9.0-rc5 4.9.0-rc5 vanilla hopcpu-v3 Hmeansend-64 178.38 ( 0.00%) 256.74 ( 43.93%) Hmeansend-128351.49 (

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

2016-11-28 Thread Vlastimil Babka
On 11/27/2016 02:19 PM, Mel Gorman wrote: 2-socket modern machine 4.9.0-rc5 4.9.0-rc5 vanilla hopcpu-v3 Hmeansend-64 178.38 ( 0.00%) 256.74 ( 43.93%) Hmeansend-128351.49 (

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

2016-11-27 Thread Mel Gorman
Changelog since v2 o Correct initialisation to avoid -Woverflow warning SLUB has been the default small kernel object allocator for quite some time but it is not universally used due to performance concerns and a reliance on high-order pages. The high-order concerns has two major components --

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

2016-11-27 Thread Mel Gorman
Changelog since v2 o Correct initialisation to avoid -Woverflow warning SLUB has been the default small kernel object allocator for quite some time but it is not universally used due to performance concerns and a reliance on high-order pages. The high-order concerns has two major components --