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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 14 Jul 2016 10:22:04 +0900
From:	Minchan Kim <minchan@...nel.org>
To:	Mel Gorman <mgorman@...hsingularity.net>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux-MM <linux-mm@...ck.org>,
	Johannes Weiner <hannes@...xchg.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/4] mm, vmscan: Have kswapd reclaim from all zones if
 reclaiming and buffer_heads_over_limit -fix

On Wed, Jul 13, 2016 at 11:00:01AM +0100, Mel Gorman wrote:
> Johannes reported that the comment about buffer_heads_over_limit in
> balance_pgdat only made sense in the context of the patch. This patch
> clarifies the reasoning and how it applies to 32 and 64 bit systems.
> 
> This is a fix to the mmotm patch
> mm-vmscan-have-kswapd-reclaim-from-all-zones-if-reclaiming-and-buffer_heads_over_limit.patch
> 
> Suggested-by: Johannes Weiner <hannes@...xchg.org>
> Signed-off-by: Mel Gorman <mgorman@...hsingularity.net>
> ---
>  mm/vmscan.c | 13 +++++++------
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index d079210d46ee..21eae17ee730 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -3131,12 +3131,13 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int classzone_idx)
>  
>  		/*
>  		 * If the number of buffer_heads exceeds the maximum allowed
> -		 * then consider reclaiming from all zones. This is not
> -		 * specific to highmem which may not exist but it is it is
> -		 * expected that buffer_heads are stripped in writeback.
> -		 * Reclaim may still not go ahead if all eligible zones
> -		 * for the original allocation request are balanced to
> -		 * avoid excessive reclaim from kswapd.
> +		 * then consider reclaiming from all zones. This has a dual
> +		 * purpose -- on 64-bit systems it is expected that
> +		 * buffer_heads are stripped during active rotation. On 32-bit
> +		 * systems, highmem pages can pin lowmem memory and shrinking
> +		 * buffers can relieve lowmem pressure. Reclaim may still not

It's good but I hope we can make it more clear.

On 32-bit systems, highmem pages can pin lowmem pages storing buffer_heads
so shrinking highmem pages can relieve lowmem pressure.

If you don't think it's much readable compared to yours, feel free to drop.

Thanks.

Powered by blists - more mailing lists