On Tue, Nov 22, 2011 at 01:08:48PM +0200, Gilad Ben-Yossef wrote:
> Calculate a cpumask of CPUs with per-cpu pages in any zone and only send an IPI requesting CPUs to drain these pages to the buddy allocator if they actually have pages when asked to flush.
>
> The code path of memory allocation failure for CPUMASK_OFFSTACK=y config was tested using fault injection framework.
>
> Signed-off-by: Gilad Ben-Yossef <gilad@xxxxxxxxxxxxx>
> Acked-by: Christoph Lameter <cl@xxxxxxxxx>
> CC: Chris Metcalf <cmetcalf@xxxxxxxxxx>
> CC: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
> CC: Frederic Weisbecker <fweisbec@xxxxxxxxx>
> CC: Russell King <linux@xxxxxxxxxxxxxxxx>
> CC: linux-mm@xxxxxxxxx
> CC: Pekka Enberg <penberg@xxxxxxxxxx>
> CC: Matt Mackall <mpm@xxxxxxxxxxx>
> CC: Sasha Levin <levinsasha928@xxxxxxxxx>
> CC: Rik van Riel <riel@xxxxxxxxxx>
> CC: Andi Kleen <andi@xxxxxxxxxxxxxx>
> ---
> mm/page_alloc.c | 18 +++++++++++++++++-
> 1 files changed, 17 insertions(+), 1 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 9dd443d..a3efdf1 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1119,7 +1119,23 @@ void drain_local_pages(void *arg)
> */
> void drain_all_pages(void)
> {
> - on_each_cpu(drain_local_pages, NULL, 1);
> + int cpu;
> + struct zone *zone;
> + cpumask_var_t cpus;
> + struct per_cpu_pageset *pcp;
> +
> + if (likely(zalloc_cpumask_var(&cpus, GFP_ATOMIC))) {
> + for_each_online_cpu(cpu) {
> + for_each_populated_zone(zone) {
> + pcp = per_cpu_ptr(zone->pageset, cpu);
> + if (pcp->pcp.count)
> + cpumask_set_cpu(cpu, cpus);
> + }
> + }
> + on_each_cpu_mask(cpus, drain_local_pages, NULL, 1);
> + free_cpumask_var(cpus);
The indenting there is very weird but easily fixed.
A greater concern is that we are calling zalloc_cpumask_var() from the
direct reclaim path when we are already under memory pressure. How often
is this path hit and how often does the allocation fail?
Related to that, calling into the page allocator again for
zalloc_cpumask_var is not cheap. Does reducing the number of IPIs
offset the cost of calling into the allocator again? How often does it
offset the cost and how often does it end up costing more? I guess that
would heavily depend on the number of CPUs and how many of them have
pages in their per-cpu buffer. Basically, sometimes we *might* save but
it comes at a definite cost of calling into the page allocator again.
The patch looks ok functionally but I'm skeptical that it really helps
performance.
> + } else
> + on_each_cpu(drain_local_pages, NULL, 1);
> }
>
> #ifdef CONFIG_HIBERNATION
--
Mel Gorman
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>