linux-kernel - Re: [PATCH v4 5/5] mm: Only IPI CPUs to drain local pages if they exist

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20111223102810.GT3487@suse.de>
Date:	Fri, 23 Dec 2011 10:28:10 +0000
From:	Mel Gorman <mgorman@...e.de>
To:	Gilad Ben-Yossef <gilad@...yossef.com>
Cc:	linux-kernel@...r.kernel.org, Chris Metcalf <cmetcalf@...era.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Russell King <linux@....linux.org.uk>, linux-mm@...ck.org,
	Pekka Enberg <penberg@...nel.org>,
	Matt Mackall <mpm@...enic.com>,
	Sasha Levin <levinsasha928@...il.com>,
	Rik van Riel <riel@...hat.com>,
	Andi Kleen <andi@...stfloor.org>
Subject: Re: [PATCH v4 5/5] mm: Only IPI CPUs to drain local pages if they
 exist

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@...yossef.com>
> Acked-by: Christoph Lameter <cl@...ux.com>
> CC: Chris Metcalf <cmetcalf@...era.com>
> CC: Peter Zijlstra <a.p.zijlstra@...llo.nl>
> CC: Frederic Weisbecker <fweisbec@...il.com>
> CC: Russell King <linux@....linux.org.uk>
> CC: linux-mm@...ck.org
> CC: Pekka Enberg <penberg@...nel.org>
> CC: Matt Mackall <mpm@...enic.com>
> CC: Sasha Levin <levinsasha928@...il.com>
> CC: Rik van Riel <riel@...hat.com>
> CC: Andi Kleen <andi@...stfloor.org>
> ---
>  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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/