From: Mel Gorman <mel@csn.ul.ie>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 5/13] Choose pages from the per cpu list-based on migration type
Date: Tue, 14 Jul 2009 10:14:38 +0100 [thread overview]
Message-ID: <20090714091438.GA28569@csn.ul.ie> (raw)
In-Reply-To: <20090713121628.bde62c65.akpm@linux-foundation.org>
On Mon, Jul 13, 2009 at 12:16:28PM -0700, Andrew Morton wrote:
> On Mon, 10 Sep 2007 12:21:51 +0100 (IST)
> Mel Gorman <mel@csn.ul.ie> wrote:
> >
>
> A somewhat belated review comment.
>
> > The freelists for each migrate type can slowly become polluted due to the
> > per-cpu list. Consider what happens when the following happens
> >
> > 1. A 2^pageblock_order list is reserved for __GFP_MOVABLE pages
> > 2. An order-0 page is allocated from the newly reserved block
> > 3. The page is freed and placed on the per-cpu list
> > 4. alloc_page() is called with GFP_KERNEL as the gfp_mask
> > 5. The per-cpu list is used to satisfy the allocation
> >
> > This results in a kernel page is in the middle of a migratable region. This
> > patch prevents this leak occuring by storing the MIGRATE_ type of the page in
> > page->private. On allocate, a page will only be returned of the desired type,
> > else more pages will be allocated. This may temporarily allow a per-cpu list
> > to go over the pcp->high limit but it'll be corrected on the next free. Care
> > is taken to preserve the hotness of pages recently freed.
> >
> > The additional code is not measurably slower for the workloads we've tested.
>
> It sure looks slower.
>
> > Signed-off-by: Mel Gorman <mel@csn.ul.ie>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > ---
> >
> > mm/page_alloc.c | 18 ++++++++++++++++--
> > 1 file changed, 16 insertions(+), 2 deletions(-)
> >
> > diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.23-rc5-004-split-the-free-lists-for-movable-and-unmovable-allocations/mm/page_alloc.c linux-2.6.23-rc5-005-choose-pages-from-the-per-cpu-list-based-on-migration-type/mm/page_alloc.c
> > --- linux-2.6.23-rc5-004-split-the-free-lists-for-movable-and-unmovable-allocations/mm/page_alloc.c 2007-09-02 16:19:34.000000000 +0100
> > +++ linux-2.6.23-rc5-005-choose-pages-from-the-per-cpu-list-based-on-migration-type/mm/page_alloc.c 2007-09-02 16:20:09.000000000 +0100
> > @@ -757,7 +757,8 @@ static int rmqueue_bulk(struct zone *zon
> > struct page *page = __rmqueue(zone, order, migratetype);
> > if (unlikely(page == NULL))
> > break;
> > - list_add_tail(&page->lru, list);
> > + list_add(&page->lru, list);
> > + set_page_private(page, migratetype);
> > }
> > spin_unlock(&zone->lock);
> > return i;
> > @@ -884,6 +885,7 @@ static void fastcall free_hot_cold_page(
> > local_irq_save(flags);
> > __count_vm_event(PGFREE);
> > list_add(&page->lru, &pcp->list);
> > + set_page_private(page, get_pageblock_migratetype(page));
> > pcp->count++;
> > if (pcp->count >= pcp->high) {
> > free_pages_bulk(zone, pcp->batch, &pcp->list, 0);
> > @@ -948,7 +950,19 @@ again:
> > if (unlikely(!pcp->count))
> > goto failed;
> > }
> > - page = list_entry(pcp->list.next, struct page, lru);
> > +
> > + /* Find a page of the appropriate migrate type */
> > + list_for_each_entry(page, &pcp->list, lru)
> > + if (page_private(page) == migratetype)
> > + break;
>
> We're doing a linear search through the per-cpu magaznines right there
> in the page allocator hot path. Even if the search matches the first
> element, the setup costs will matter.
>
> Surely we can make this search go away with a better choice of data
> structures?
>
I have a patch that expands the per-cpu structure and eliminates the search
and I made various attempts at reducing the setup cost (e.g. checking if
the first element suited before starting the search). However, I wasn't been
able to show for definite it made anything faster but it did increase
the size of a per-cpu structure.
>
> > + /* Allocate more to the pcp list if necessary */
> > + if (unlikely(&page->lru == &pcp->list)) {
> > + pcp->count += rmqueue_bulk(zone, 0,
> > + pcp->batch, &pcp->list, migratetype);
> > + page = list_entry(pcp->list.next, struct page, lru);
> > + }
> > +
> > list_del(&page->lru);
> > pcp->count--;
> > } else {
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-07-14 8:44 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-10 11:20 [PATCH 0/13] Reduce external fragmentation by grouping pages by mobility v30 Mel Gorman
2007-09-10 11:20 ` [PATCH 1/13] ia64: parse kernel parameter hugepagesz= in early boot, ia64: parse kernel parameter hugepagesz= in early boot Mel Gorman
2007-09-10 11:20 ` [PATCH 2/13] Add a bitmap that is used to track flags affecting a block of pages, Add a bitmap that is used to track flags affecting a block of pages Mel Gorman
2007-09-10 11:21 ` [PATCH 3/13] Fix corruption of memmap on ia64-sparsemem when mem_section is not a power of 2, Fix corruption of memmap on ia64-sparsemem when mem_section is not a power of 2 Mel Gorman
2007-09-10 11:21 ` [PATCH 4/13] Split the free lists for movable and unmovable allocations, Split the free lists for movable and unmovable allocations Mel Gorman
2007-09-10 11:21 ` [PATCH 5/13] Choose pages from the per cpu list-based on migration type, Choose pages from the per cpu list-based on migration type Mel Gorman
2009-07-13 19:16 ` [PATCH 5/13] " Andrew Morton
2009-07-14 9:14 ` Mel Gorman [this message]
2007-09-10 11:22 ` [PATCH 6/13] Group short-lived and reclaimable kernel allocations, Group short-lived and reclaimable kernel allocations Mel Gorman
2007-09-10 19:44 ` Paul Jackson
2007-09-10 21:15 ` Mel Gorman
2007-09-10 11:22 ` [PATCH 7/13] Drain per-cpu lists when high-order allocations fail, Drain per-cpu lists when high-order allocations fail Mel Gorman
2007-09-10 15:05 ` [PATCH 7/13] " Nick Piggin
2007-09-11 9:34 ` Mel Gorman
2007-09-10 11:22 ` [PATCH 8/13] Move free pages between lists on steal, Move free pages between lists on steal Mel Gorman
2007-09-10 11:23 ` [PATCH 9/13] Do not group pages by mobility type on low memory systems, Do not group pages by mobility type on low memory systems Mel Gorman
2007-09-10 11:23 ` [PATCH 10/13] Bias the location of pages freed for min_free_kbytes in the same pageblock_nr_pages areas, Bias the location of pages freed for min_free_kbytes in the same pageblock_nr_pages areas Mel Gorman
2007-09-10 11:23 ` [PATCH 11/13] Bias the placement of kernel pages at lower pfns, Bias the placement of kernel pages at lower pfns Mel Gorman
2007-09-10 11:24 ` [PATCH 12/13] Be more agressive about stealing when MIGRATE_RECLAIMABLE allocations fallback, Be more agressive about stealing when MIGRATE_RECLAIMABLE allocations fallback Mel Gorman
2007-09-10 11:24 ` [PATCH 13/13] Print out statistics in relation to fragmentation avoidance to /proc/pagetypeinfo, Print out statistics in relation to fragmentation avoidance to /proc/pagetypeinfo Mel Gorman
2007-09-14 1:01 ` [PATCH 0/13] Reduce external fragmentation by grouping pages by mobility v30 Andrew Morton
2007-09-14 14:33 ` Mel Gorman
2007-09-16 10:34 ` Andrew Morton
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=20090714091438.GA28569@csn.ul.ie \
--to=mel@csn.ul.ie \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox