linux-kernel - [PATCH v6] mm: vmscan: do not pass reclaimed slab to vmpressure

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>] [day] [month] [year] [list]
Message-Id: <1487841770-26120-1-git-send-email-vinmenon@codeaurora.org>
Date:   Thu, 23 Feb 2017 14:52:50 +0530
From:   Vinayak Menon <vinmenon@...eaurora.org>
To:     akpm@...ux-foundation.org, hannes@...xchg.org,
        mgorman@...hsingularity.net, vbabka@...e.cz, mhocko@...e.com,
        riel@...hat.com, vdavydov.dev@...il.com,
        anton.vorontsov@...aro.org, minchan@...nel.org,
        shashim@...eaurora.org
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Vinayak Menon <vinmenon@...eaurora.org>
Subject: [PATCH v6] mm: vmscan: do not pass reclaimed slab to vmpressure

During global reclaim, the nr_reclaimed passed to vmpressure includes the
pages reclaimed from slab.  But the corresponding scanned slab pages is
not passed.  There is an impact to the vmpressure values because of this.
While moving from kernel version 3.18 to 4.4, a difference is seen in the
vmpressure values for the same workload resulting in a different behaviour
of the vmpressure consumer.  One such case is of a vmpressure based
lowmemorykiller.  It is observed that the vmpressure events are received
late and less in number resulting in tasks not being killed at the right
time. In this use case, The number of critical vmpressure events received
is around 50% less on 4.4 than 3.18. The following numbers show the impact
on reclaim activity due to the change in behaviour of lowmemorykiller on a
4GB device.  The test launches a number of apps in sequence and repeats it
multiple times. The difference in reclaim behaviour is because of lesser
number of kills and kills happening late, resulting in more swapping and
page cache reclaim.

                      v4.4           v3.18
pgpgin                163016456      145617236
pgpgout               4366220        4188004
workingset_refault    29857868       26781854
workingset_activate   6293946        5634625
pswpin                1327601        1133912
pswpout               3593842        3229602
pgalloc_dma           99520618       94402970
pgalloc_normal        104046854      98124798
pgfree                203772640      192600737
pgmajfault            2126962        1851836
pgsteal_kswapd_dma    19732899       18039462
pgsteal_kswapd_normal 19945336       17977706
pgsteal_direct_dma    206757         131376
pgsteal_direct_normal 236783         138247
pageoutrun            116622         108370
allocstall            7220           4684
compact_stall         931            856

The lowmemorykiller example above is just for indicating the difference in
vmpressure events between 4.4 and 3.18.

Do not consider reclaimed slab pages for vmpressure calculation. The
reclaimed pages from slab can be excluded because the freeing of a page by
slab shrinking depends on each slab's object population, making the cost
model (i.e. scan:free) different from that of LRU.  Also, not every
shrinker accounts the pages it reclaims. Ideally the pages reclaimed from
slab should be passed to vmpressure, otherwise higher vmpressure levels can
be triggered even when there is a reclaim progress.  But accounting only
the reclaimed slab pages without the scanned, and adding something which
does not fit into the cost model just adds noise to the vmpressure values.

Fixes: 6b4f7799c6a5 ("mm: vmscan: invoke slab shrinkers from shrink_zone()")
Link: http://lkml.kernel.org/r/1486641577-11685-2-git-send-email-vinmenon@codeaurora.org
Acked-by: Minchan Kim <minchan@...nel.org>
Signed-off-by: Vinayak Menon <vinmenon@...eaurora.org>
Cc: Johannes Weiner <hannes@...xchg.org>
Cc: Mel Gorman <mgorman@...hsingularity.net>
Cc: Vlastimil Babka <vbabka@...e.cz>
Cc: Michal Hocko <mhocko@...e.com>
Cc: Rik van Riel <riel@...hat.com>
Cc: Vladimir Davydov <vdavydov.dev@...il.com>
Cc: Anton Vorontsov <anton.vorontsov@...aro.org>
Cc: Shiraz Hashim <shashim@...eaurora.org>
Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
---
v6: Modifying the changelog as per Michal's suggestion

 mm/vmscan.c | 17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 70aa739..26c3b40 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2603,16 +2603,23 @@ static bool shrink_node(pg_data_t *pgdat, struct scan_control *sc)
 				    sc->nr_scanned - nr_scanned,
 				    node_lru_pages);
 
+		/*
+		 * Record the subtree's reclaim efficiency. The reclaimed
+		 * pages from slab is excluded here because the corresponding
+		 * scanned pages is not accounted. Moreover, freeing a page
+		 * by slab shrinking depends on each slab's object population,
+		 * making the cost model (i.e. scan:free) different from that
+		 * of LRU.
+		 */
+		vmpressure(sc->gfp_mask, sc->target_mem_cgroup, true,
+			   sc->nr_scanned - nr_scanned,
+			   sc->nr_reclaimed - nr_reclaimed);
+
 		if (reclaim_state) {
 			sc->nr_reclaimed += reclaim_state->reclaimed_slab;
 			reclaim_state->reclaimed_slab = 0;
 		}
 
-		/* Record the subtree's reclaim efficiency */
-		vmpressure(sc->gfp_mask, sc->target_mem_cgroup, true,
-			   sc->nr_scanned - nr_scanned,
-			   sc->nr_reclaimed - nr_reclaimed);
-
 		if (sc->nr_reclaimed - nr_reclaimed)
 			reclaimable = true;
 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation