From: Mel Gorman <mel@csn.ul.ie>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH 7/13] Drain per-cpu lists when high-order allocations fail
Date: Tue, 11 Sep 2007 10:34:27 +0100 [thread overview]
Message-ID: <1189503267.32731.6.camel@localhost> (raw)
In-Reply-To: <200709110105.25544.nickpiggin@yahoo.com.au>
On Tue, 2007-09-11 at 01:05 +1000, Nick Piggin wrote:
> On Monday 10 September 2007 21:22, Mel Gorman wrote:
> > Per-cpu pages can accidentally cause fragmentation because they are free,
> > but pinned pages in an otherwise contiguous block. When this patch is
> > applied, the per-cpu caches are drained after the direct-reclaim is entered
> > if the requested order is greater than 0. It simply reuses the code used
> > by suspend and hotplug.
>
> Does this help? I have a more general version which could go in
> instead (independently of the anti fragmentation patches).
Yes, it does help. It's noticable when one is trying to get as much
memory in hugepages as possible. It reaches a certain point where
hugepages are free but pinned due to per-cpu pages. This "certain point"
depends on the number of CPUs as a ratio to the size of physical memory
as well as a certain degree of randomness as the location of per-cpu
pages is not predictable. Worst case is not being able to allocate
something like (NR_CPUS * pcp->high * 2) hugepages even if they are
otherwise free.
By all means if you have a general version, send it and I'll take a
look. If it's more general and nicer but still can be used to drain the
per-cpu lists when high-order allocations fail, I'm all for it.
Thanks Nick
> > Signed-off-by: Mel Gorman <mel@csn.ul.ie>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > ---
> >
> > mm/page_alloc.c | 24 +++++++++++++++++++++++-
> > 1 file changed, 23 insertions(+), 1 deletion(-)
> >
> > diff -rup -X /usr/src/patchset-0.6/bin//dontdiff
> > linux-2.6.23-rc5-006-group-short-lived-and-reclaimable-kernel-allocations/m
> >m/page_alloc.c
> > linux-2.6.23-rc5-007-drain-per-cpu-lists-when-high-order-allocations-fail/m
> >m/page_alloc.c ---
> > linux-2.6.23-rc5-006-group-short-lived-and-reclaimable-kernel-allocations/m
> >m/page_alloc.c 2007-09-02 16:20:31.000000000 +0100 +++
> > linux-2.6.23-rc5-007-drain-per-cpu-lists-when-high-order-allocations-fail/m
> >m/page_alloc.c 2007-09-02 16:20:48.000000000 +0100 @@ -852,6 +852,7 @@ void
> > mark_free_pages(struct zone *zone)
> > }
> > spin_unlock_irqrestore(&zone->lock, flags);
> > }
> > +#endif /* CONFIG_PM */
> >
> > /*
> > * Spill all of this CPU's per-cpu pages back into the buddy allocator.
> > @@ -864,7 +865,25 @@ void drain_local_pages(void)
> > __drain_pages(smp_processor_id());
> > local_irq_restore(flags);
> > }
> > -#endif /* CONFIG_HIBERNATION */
> > +
> > +void smp_drain_local_pages(void *arg)
> > +{
> > + drain_local_pages();
> > +}
> > +
> > +/*
> > + * Spill all the per-cpu pages from all CPUs back into the buddy allocator
> > + */
> > +void drain_all_local_pages(void)
> > +{
> > + unsigned long flags;
> > +
> > + local_irq_save(flags);
> > + __drain_pages(smp_processor_id());
> > + local_irq_restore(flags);
> > +
> > + smp_call_function(smp_drain_local_pages, NULL, 0, 1);
> > +}
> >
> > /*
> > * Free a 0-order page
> > @@ -1452,6 +1471,9 @@ nofail_alloc:
> >
> > cond_resched();
> >
> > + if (order != 0)
> > + drain_all_local_pages();
> > +
> > if (likely(did_some_progress)) {
> > page = get_page_from_freelist(gfp_mask, order,
> > zonelist, alloc_flags);
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mel@csn.ul.ie>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH 7/13] Drain per-cpu lists when high-order allocations fail
Date: Tue, 11 Sep 2007 10:34:27 +0100 [thread overview]
Message-ID: <1189503267.32731.6.camel@localhost> (raw)
In-Reply-To: <200709110105.25544.nickpiggin@yahoo.com.au>
On Tue, 2007-09-11 at 01:05 +1000, Nick Piggin wrote:
> On Monday 10 September 2007 21:22, Mel Gorman wrote:
> > Per-cpu pages can accidentally cause fragmentation because they are free,
> > but pinned pages in an otherwise contiguous block. When this patch is
> > applied, the per-cpu caches are drained after the direct-reclaim is entered
> > if the requested order is greater than 0. It simply reuses the code used
> > by suspend and hotplug.
>
> Does this help? I have a more general version which could go in
> instead (independently of the anti fragmentation patches).
Yes, it does help. It's noticable when one is trying to get as much
memory in hugepages as possible. It reaches a certain point where
hugepages are free but pinned due to per-cpu pages. This "certain point"
depends on the number of CPUs as a ratio to the size of physical memory
as well as a certain degree of randomness as the location of per-cpu
pages is not predictable. Worst case is not being able to allocate
something like (NR_CPUS * pcp->high * 2) hugepages even if they are
otherwise free.
By all means if you have a general version, send it and I'll take a
look. If it's more general and nicer but still can be used to drain the
per-cpu lists when high-order allocations fail, I'm all for it.
Thanks Nick
> > Signed-off-by: Mel Gorman <mel@csn.ul.ie>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > ---
> >
> > mm/page_alloc.c | 24 +++++++++++++++++++++++-
> > 1 file changed, 23 insertions(+), 1 deletion(-)
> >
> > diff -rup -X /usr/src/patchset-0.6/bin//dontdiff
> > linux-2.6.23-rc5-006-group-short-lived-and-reclaimable-kernel-allocations/m
> >m/page_alloc.c
> > linux-2.6.23-rc5-007-drain-per-cpu-lists-when-high-order-allocations-fail/m
> >m/page_alloc.c ---
> > linux-2.6.23-rc5-006-group-short-lived-and-reclaimable-kernel-allocations/m
> >m/page_alloc.c 2007-09-02 16:20:31.000000000 +0100 +++
> > linux-2.6.23-rc5-007-drain-per-cpu-lists-when-high-order-allocations-fail/m
> >m/page_alloc.c 2007-09-02 16:20:48.000000000 +0100 @@ -852,6 +852,7 @@ void
> > mark_free_pages(struct zone *zone)
> > }
> > spin_unlock_irqrestore(&zone->lock, flags);
> > }
> > +#endif /* CONFIG_PM */
> >
> > /*
> > * Spill all of this CPU's per-cpu pages back into the buddy allocator.
> > @@ -864,7 +865,25 @@ void drain_local_pages(void)
> > __drain_pages(smp_processor_id());
> > local_irq_restore(flags);
> > }
> > -#endif /* CONFIG_HIBERNATION */
> > +
> > +void smp_drain_local_pages(void *arg)
> > +{
> > + drain_local_pages();
> > +}
> > +
> > +/*
> > + * Spill all the per-cpu pages from all CPUs back into the buddy allocator
> > + */
> > +void drain_all_local_pages(void)
> > +{
> > + unsigned long flags;
> > +
> > + local_irq_save(flags);
> > + __drain_pages(smp_processor_id());
> > + local_irq_restore(flags);
> > +
> > + smp_call_function(smp_drain_local_pages, NULL, 0, 1);
> > +}
> >
> > /*
> > * Free a 0-order page
> > @@ -1452,6 +1471,9 @@ nofail_alloc:
> >
> > cond_resched();
> >
> > + if (order != 0)
> > + drain_all_local_pages();
> > +
> > if (likely(did_some_progress)) {
> > page = get_page_from_freelist(gfp_mask, order,
> > zonelist, alloc_flags);
--
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:[~2007-09-11 8:34 UTC|newest]
Thread overview: 46+ 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 ` Mel Gorman
2007-09-10 11:20 ` [PATCH 1/13] ia64: parse kernel parameter hugepagesz= in early boot Mel Gorman
2007-09-10 11:20 ` [PATCH 1/13] 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 Mel Gorman
2007-09-10 11:20 ` [PATCH 2/13] 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 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, " Mel Gorman
2007-09-10 11:21 ` [PATCH 4/13] Split the free lists for movable and unmovable allocations Mel Gorman
2007-09-10 11:21 ` [PATCH 4/13] 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 Mel Gorman
2007-09-10 11:21 ` [PATCH 5/13] 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-13 19:16 ` Andrew Morton
2009-07-14 9:14 ` Mel Gorman
2009-07-14 9:14 ` Mel Gorman
2007-09-10 11:22 ` [PATCH 6/13] Group short-lived and reclaimable kernel allocations Mel Gorman
2007-09-10 11:22 ` [PATCH 6/13] Group short-lived and reclaimable kernel allocations, " Mel Gorman
2007-09-10 19:44 ` Paul Jackson
2007-09-10 19:44 ` Paul Jackson
2007-09-10 21:15 ` Mel Gorman
2007-09-10 21:15 ` Mel Gorman
2007-09-10 11:22 ` [PATCH 7/13] Drain per-cpu lists when high-order allocations fail Mel Gorman
2007-09-10 11:22 ` [PATCH 7/13] Drain per-cpu lists when high-order allocations fail, " Mel Gorman
2007-09-10 15:05 ` [PATCH 7/13] " Nick Piggin
2007-09-10 15:05 ` Nick Piggin
2007-09-11 9:34 ` Mel Gorman [this message]
2007-09-11 9:34 ` Mel Gorman
2007-09-10 11:22 ` [PATCH 8/13] Move free pages between lists on steal Mel Gorman
2007-09-10 11:22 ` [PATCH 8/13] 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 Mel Gorman
2007-09-10 11:23 ` [PATCH 9/13] 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 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, " Mel Gorman
2007-09-10 11:23 ` [PATCH 11/13] Bias the placement of kernel pages at lower pfns Mel Gorman
2007-09-10 11:23 ` [PATCH 11/13] 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 Mel Gorman
2007-09-10 11:24 ` [PATCH 12/13] 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 Mel Gorman
2007-09-10 11:24 ` [PATCH 13/13] 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 1:01 ` Andrew Morton
2007-09-14 14:33 ` Mel Gorman
2007-09-14 14:33 ` Mel Gorman
2007-09-16 10:34 ` Andrew Morton
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=1189503267.32731.6.camel@localhost \
--to=mel@csn.ul.ie \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nickpiggin@yahoo.com.au \
/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.