All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Mel Gorman <mgorman@techsingularity.net>
Cc: Linux-MM <linux-mm@kvack.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Michal Hocko <mhocko@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	brouer@redhat.com
Subject: Re: [PATCH 2/2] mm/page_alloc: Allow high-order pages to be stored on the per-cpu lists
Date: Wed, 2 Jun 2021 15:53:22 +0200	[thread overview]
Message-ID: <20210602155322.6f286ea4@carbon> (raw)
In-Reply-To: <20210601124533.GU30378@techsingularity.net>

On Tue, 1 Jun 2021 13:45:33 +0100
Mel Gorman <mgorman@techsingularity.net> wrote:

> On Mon, May 31, 2021 at 05:23:38PM +0200, Jesper Dangaard Brouer wrote:
> > On Mon, 31 May 2021 13:04:12 +0100
> > Mel Gorman <mgorman@techsingularity.net> wrote:
> >   
> > > The per-cpu page allocator (PCP) only stores order-0 pages. This means
> > > that all THP and "cheap" high-order allocations including SLUB contends
> > > on the zone->lock. This patch extends the PCP allocator to store THP and
> > > "cheap" high-order pages. Note that struct per_cpu_pages increases in
> > > size to 256 bytes (4 cache lines) on x86-64.
> > > 
> > > Note that this is not necessarily a universal performance win because of
> > > how it is implemented. High-order pages can cause pcp->high to be exceeded
> > > prematurely for lower-orders so for example, a large number of THP pages
> > > being freed could release order-0 pages from the PCP lists. Hence, much
> > > depends on the allocation/free pattern as observed by a single CPU to
> > > determine if caching helps or hurts a particular workload.
> > > 
> > > That said, basic performance testing passed. The following is a netperf
> > > UDP_STREAM test which hits the relevant patches as some of the network
> > > allocations are high-order.  
> > 
> > This series[1] looks very interesting!  I confirm that some network
> > allocations do use high-order allocations.  Thus, I think this will
> > increase network performance in general, like you confirm below:
> >   
> 
> Would you be able to do a small test on a real high-speed network? It's
> something I can do easily myself in a few weeks but I do not have testbed
> readily available at the moment. It's ok if you do not have the time,
> it would just be nice if I could include independent results in the
> changelog if the results are positive. 

I don't have time right now.

If others have time, you can use this git tree provided by Mel:

 https://git.kernel.org/pub/scm/linux/kernel/git/mel/linux.git/
 git://git.kernel.org/pub/scm/linux/kernel/git/mel/linux.git
 branch: mm-pcphighorder-v1r7


> Alternatively, a negative result would mean going back to the drawing
> board :)

I'm confident that this will be a positive performance change. (I
remember we played with similar patches back in 2017).

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer


  reply	other threads:[~2021-06-02 13:53 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-31 12:04 [RFC PATCH 0/2] Allow high order pages to be stored on PCP Mel Gorman
2021-05-31 12:04 ` [PATCH 1/2] mm/page_alloc: Move free_the_page Mel Gorman
2021-05-31 12:04 ` [PATCH 2/2] mm/page_alloc: Allow high-order pages to be stored on the per-cpu lists Mel Gorman
2021-05-31 15:23   ` Jesper Dangaard Brouer
2021-06-01 12:45     ` Mel Gorman
2021-06-02 13:53       ` Jesper Dangaard Brouer [this message]
2021-06-03  8:46 [PATCH 0/2] Allow high order pages to be stored on PCP Mel Gorman
2021-06-03  8:46 ` [PATCH 2/2] mm/page_alloc: Allow high-order pages to be stored on the per-cpu lists Mel Gorman
2021-06-03 11:12   ` Vlastimil Babka
2021-06-03 12:34     ` Mel Gorman
2021-06-03 13:04       ` Vlastimil Babka
2021-06-03 14:22 [PATCH 0/2] Allow high order pages to be stored on PCP v2 Mel Gorman
2021-06-03 14:22 ` [PATCH 2/2] mm/page_alloc: Allow high-order pages to be stored on the per-cpu lists Mel Gorman
2021-06-09 18:30   ` Zi Yan
2021-06-10 11:18     ` Mel Gorman
2021-06-10 11:40       ` Zi Yan
2021-06-10 22:59         ` Andrew Morton
2021-06-11  0:38           ` Stephen Rothwell
2021-06-11  8:10         ` Mel Gorman
2021-06-11  8:34         ` Mel Gorman
2021-06-11 12:17           ` Zi Yan
2021-06-11 13:58             ` Mel Gorman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210602155322.6f286ea4@carbon \
    --to=brouer@redhat.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.