All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@techsingularity.net>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Linux-MM <linux-mm@kvack.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Matthew Wilcox <willy@infradead.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	Michal Hocko <mhocko@kernel.org>,
	Nicholas Piggin <npiggin@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/6] mm/page_alloc: Scale the number of pages that are batch freed
Date: Mon, 24 May 2021 10:12:20 +0100	[thread overview]
Message-ID: <20210524091220.GC30378@techsingularity.net> (raw)
In-Reply-To: <8646d3ad-345f-7ec7-fe4a-ada2680487a3@intel.com>

On Fri, May 21, 2021 at 03:36:05PM -0700, Dave Hansen wrote:
> ...
> > +static int nr_pcp_free(struct per_cpu_pages *pcp, int high, int batch)
> > +{
> > +	int min_nr_free, max_nr_free;
> > +
> > +	/* Check for PCP disabled or boot pageset */
> > +	if (unlikely(high < batch))
> > +		return 1;
> > +
> > +	min_nr_free = batch;
> > +	max_nr_free = high - batch;
> 
> I puzzled over this for a minute.  I *think* it means to say: "Leave at
> least one batch worth of pages in the pcp at all times so that the next
> allocation can still be satisfied from this pcp."
> 

Yes, I added a comment.

> > +	batch <<= pcp->free_factor;
> > +	if (batch < max_nr_free)
> > +		pcp->free_factor++;
> > +	batch = clamp(batch, min_nr_free, max_nr_free);
> > +
> > +	return batch;
> > +}
> > +
> >  static void free_unref_page_commit(struct page *page, unsigned long pfn,
> >  				   int migratetype)
> >  {
> >  	struct zone *zone = page_zone(page);
> >  	struct per_cpu_pages *pcp;
> > +	int high;
> >  
> >  	__count_vm_event(PGFREE);
> >  	pcp = this_cpu_ptr(zone->per_cpu_pageset);
> >  	list_add(&page->lru, &pcp->lists[migratetype]);
> >  	pcp->count++;
> > -	if (pcp->count >= READ_ONCE(pcp->high))
> > -		free_pcppages_bulk(zone, READ_ONCE(pcp->batch), pcp);
> > +	high = READ_ONCE(pcp->high);
> > +	if (pcp->count >= high) {
> > +		int batch = READ_ONCE(pcp->batch);
> > +
> > +		free_pcppages_bulk(zone, nr_pcp_free(pcp, high, batch), pcp);
> > +	}
> >  }
> >  
> >  /*
> > @@ -3531,6 +3555,7 @@ static struct page *rmqueue_pcplist(struct zone *preferred_zone,
> >  
> >  	local_lock_irqsave(&pagesets.lock, flags);
> >  	pcp = this_cpu_ptr(zone->per_cpu_pageset);
> > +	pcp->free_factor >>= 1;
> >  	list = &pcp->lists[migratetype];
> >  	page = __rmqueue_pcplist(zone,  migratetype, alloc_flags, pcp, list);
> >  	local_unlock_irqrestore(&pagesets.lock, flags);
> 
> A high-level description of the algorithm in the changelog would also be
> nice.  I *think* it's basically:
> 
> After hitting the high pcp mark, free one pcp->batch at a time.  But, as
> subsequent pcp free operations occur, keep doubling the size of the
> freed batches.  Cap them so that they always leave at least one
> pcp->batch worth of pages.  Scale the size back down by half whenever an
> allocation that consumes a page from the pcp occurs.
> 
> While I'd appreciate another comment or two, I do think this is worth
> doing, and the approach seems sound:
> 
> Acked-by: Dave Hansen <dave.hansen@linux.intel.com>

Thanks, I added a few additional comments.

-- 
Mel Gorman
SUSE Labs


  reply	other threads:[~2021-05-24  9:12 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-21 10:28 [RFC PATCH 0/6] Calculate pcp->high based on zone sizes and active CPUs Mel Gorman
2021-05-21 10:28 ` [PATCH 1/6] mm/page_alloc: Delete vm.percpu_pagelist_fraction Mel Gorman
2021-05-21 21:04   ` Dave Hansen
2021-05-21 10:28 ` [PATCH 2/6] mm/page_alloc: Disassociate the pcp->high from pcp->batch Mel Gorman
2021-05-21 21:52   ` Dave Hansen
2021-05-24  8:32     ` Mel Gorman
2021-05-21 10:28 ` [PATCH 3/6] mm/page_alloc: Adjust pcp->high after CPU hotplug events Mel Gorman
2021-05-21 22:13   ` Dave Hansen
2021-05-24  9:07     ` Mel Gorman
2021-05-24 15:52       ` Dave Hansen
2021-05-24 16:01         ` Mel Gorman
2021-05-21 10:28 ` [PATCH 4/6] mm/page_alloc: Scale the number of pages that are batch freed Mel Gorman
2021-05-21 22:36   ` Dave Hansen
2021-05-24  9:12     ` Mel Gorman [this message]
2021-05-21 10:28 ` [PATCH 5/6] mm/page_alloc: Limit the number of pages on PCP lists when reclaim is active Mel Gorman
2021-05-21 22:44   ` Dave Hansen
2021-05-24  9:22     ` Mel Gorman
2021-05-21 10:28 ` [PATCH 6/6] mm/page_alloc: Introduce vm.percpu_pagelist_high_fraction Mel Gorman
2021-05-21 22:57   ` Dave Hansen
2021-05-24  9:25     ` Mel Gorman
2021-05-22  2:19   ` Hillf Danton
  -- strict thread matches above, loose matches on Subject: below --
2021-05-25  8:01 [PATCH 0/6 v2] Calculate pcp->high based on zone sizes and active CPUs Mel Gorman
2021-05-25  8:01 ` [PATCH 4/6] mm/page_alloc: Scale the number of pages that are batch freed Mel Gorman
2021-05-28 11:19   ` Vlastimil Babka

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=20210524091220.GC30378@techsingularity.net \
    --to=mgorman@techsingularity.net \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=npiggin@gmail.com \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    /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.