Re: [PATCH 05/10] mm: vmscan: Do not allow kswapd to scan at maximumpriority
From: Rik van Riel
Date: Thu Mar 21 2013 - 08:31:41 EST
On 03/21/2013 06:12 AM, Mel Gorman wrote:
On Wed, Mar 20, 2013 at 09:20:14PM -0400, Rik van Riel wrote:
On 03/17/2013 09:04 AM, Mel Gorman wrote:
Page reclaim at priority 0 will scan the entire LRU as priority 0 is
considered to be a near OOM condition. Kswapd can reach priority 0 quite
easily if it is encountering a large number of pages it cannot reclaim
such as pages under writeback. When this happens, kswapd reclaims very
aggressively even though there may be no real risk of allocation failure
or OOM.
This patch prevents kswapd reaching priority 0 and trying to reclaim
the world. Direct reclaimers will still reach priority 0 in the event
of an OOM situation.
Signed-off-by: Mel Gorman <mgorman@xxxxxxx>
---
mm/vmscan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 7513bd1..af3bb6f 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2891,7 +2891,7 @@ static unsigned long balance_pgdat(pg_data_t *pgdat, int order,
*/
if (raise_priority || !this_reclaimed)
sc.priority--;
- } while (sc.priority >= 0 &&
+ } while (sc.priority >= 1 &&
!pgdat_balanced(pgdat, order, *classzone_idx));
out:
If priority 0 is way way way way way too aggressive, what makes
priority 1 safe?
The fact that priority 1 selects a sensible number of pages to reclaim and
obeys swappiness makes it a lot safer. Priority 0 does this in get_scan_count
^^^^^^^^^^^^^^^^
Ahhh, good point! We stay away from all the "emergency" code, which
kswapd should never run.
Acked-by: Rik van Riel <riel@xxxxxxxxxx>
--
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/