linux-kernel - Re: [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis

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]

Date:	Wed, 22 Jun 2016 18:00:12 +0200
From:	Vlastimil Babka <vbabka@...e.cz>
To:	Mel Gorman <mgorman@...hsingularity.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux-MM <linux-mm@...ck.org>
Cc:	Rik van Riel <riel@...riel.com>,
	Johannes Weiner <hannes@...xchg.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Michal Hocko <mhocko@...nel.org>
Subject: Re: [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node
 basis

On 06/22/2016 04:04 PM, Vlastimil Babka wrote:
> On 06/21/2016 04:15 PM, Mel Gorman wrote:
>> This patch makes reclaim decisions on a per-node basis. A reclaimer knows
>> what zone is required by the allocation request and skips pages from
>> higher zones. In many cases this will be ok because it's a GFP_HIGHMEM
>> request of some description. On 64-bit, ZONE_DMA32 requests will cause
>> some problems but 32-bit devices on 64-bit platforms are increasingly
>> rare. Historically it would have been a major problem on 32-bit with big
>> Highmem:Lowmem ratios but such configurations are also now rare and even
>> where they exist, they are not encouraged. If it really becomes a problem,
>> it'll manifest as very low reclaim efficiencies.
>>
>> Signed-off-by: Mel Gorman <mgorman@...hsingularity.net>
>
> [...]
>
>> @@ -2540,14 +2559,14 @@ static inline bool compaction_ready(struct zone *zone, int order, int classzone_
>>   * If a zone is deemed to be full of pinned pages then just give it a light
>>   * scan then give up on it.
>>   */
>> -static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc)
>> +static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc,
>> +		enum zone_type classzone_idx)
>>  {
>>  	struct zoneref *z;
>>  	struct zone *zone;
>>  	unsigned long nr_soft_reclaimed;
>>  	unsigned long nr_soft_scanned;
>>  	gfp_t orig_mask;
>> -	enum zone_type requested_highidx = gfp_zone(sc->gfp_mask);
>>
>>  	/*
>>  	 * If the number of buffer_heads in the machine exceeds the maximum
>> @@ -2560,15 +2579,20 @@ static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc)
>>
>>  	for_each_zone_zonelist_nodemask(zone, z, zonelist,
>>  					gfp_zone(sc->gfp_mask), sc->nodemask) {
>
> Using sc->reclaim_idx could be faster/nicer here than gfp_zone()?
> Although after "mm, vmscan: Update classzone_idx if buffer_heads_over_limit"
> there would need to be a variable for the highmem adjusted value - maybe reuse
> "requested_highidx"? Not important though.
>
>> -		enum zone_type classzone_idx;
>> -
>>  		if (!populated_zone(zone))
>>  			continue;
>>
>> -		classzone_idx = requested_highidx;
>> +		/*
>> +		 * Note that reclaim_idx does not change as it is the highest
>> +		 * zone reclaimed from which for empty zones is a no-op but
>> +		 * classzone_idx is used by shrink_node to test if the slabs
>> +		 * should be shrunk on a given node.
>> +		 */
>>  		while (!populated_zone(zone->zone_pgdat->node_zones +
>> -							classzone_idx))
>> +							classzone_idx)) {
>>  			classzone_idx--;
>> +			continue;

Oh and Michal's comment on Patch 20 made me realize that my objection to v6 
about possible underflow of sc->reclaim_idx and classzone_idx seems to still 
apply here for classzone_idx? Updated example: Normal zone allocation. A small 
node 0 without Normal zone will get us classzone_idx == dma32. Node 1 next in 
zonelist won't have dma/dma32 zones so we won't see node_zones + classzone_idx 
populated, and the while loop will lead to underflow of classzone_idx.
I may be missing something, but I don't really see another way around it than 
resetting classzone_idx to sc->reclaim_idx before the while loop.