From patchwork Wed May 18 06:05:52 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: KOSAKI Motohiro X-Patchwork-Id: 96127 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 1BA4AB6F64 for ; Wed, 18 May 2011 16:06:25 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753713Ab1ERGGS (ORCPT ); Wed, 18 May 2011 02:06:18 -0400 Received: from fgwmail5.fujitsu.co.jp ([192.51.44.35]:38582 "EHLO fgwmail5.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752592Ab1ERGGR (ORCPT ); Wed, 18 May 2011 02:06:17 -0400 Received: from m4.gw.fujitsu.co.jp (unknown [10.0.50.74]) by fgwmail5.fujitsu.co.jp (Postfix) with ESMTP id 668113EE0C2; Wed, 18 May 2011 15:06:14 +0900 (JST) Received: from smail (m4 [127.0.0.1]) by outgoing.m4.gw.fujitsu.co.jp (Postfix) with ESMTP id 4A6A845DF87; Wed, 18 May 2011 15:06:14 +0900 (JST) Received: from s4.gw.fujitsu.co.jp (s4.gw.fujitsu.co.jp [10.0.50.94]) by m4.gw.fujitsu.co.jp (Postfix) with ESMTP id 2806145DF81; Wed, 18 May 2011 15:06:14 +0900 (JST) Received: from s4.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id 1BFED1DB803E; Wed, 18 May 2011 15:06:14 +0900 (JST) Received: from m107.s.css.fujitsu.com (m107.s.css.fujitsu.com [10.240.81.147]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id D18D21DB8037; Wed, 18 May 2011 15:06:13 +0900 (JST) Received: from m107.css.fujitsu.com (m107 [127.0.0.1]) by m107.s.css.fujitsu.com (Postfix) with ESMTP id 7069A67000D; Wed, 18 May 2011 15:06:13 +0900 (JST) Received: from [127.0.0.1] (unknown [10.124.101.131]) by m107.s.css.fujitsu.com (Postfix) with ESMTP id 90566670003; Wed, 18 May 2011 15:06:12 +0900 (JST) X-SecurityPolicyCheck-FJ: OK by FujitsuOutboundMailChecker v1.3.1 Received: from KOSANOTE2[10.124.101.131] by KOSANOTE2 (FujitsuOutboundMailChecker v1.3.1/9992[10.124.101.131]); Wed, 18 May 2011 15:06:11 +0900 (JST) Message-ID: <4DD361C0.5030904@jp.fujitsu.com> Date: Wed, 18 May 2011 15:05:52 +0900 From: KOSAKI Motohiro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: minchan.kim@gmail.com CC: mgorman@suse.de, James.Bottomley@hansenpartnership.com, akpm@linux-foundation.org, colin.king@canonical.com, raghu.prabhu13@gmail.com, jack@suse.cz, chris.mason@oracle.com, cl@linux.com, penberg@kernel.org, riel@redhat.com, hannes@cmpxchg.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org Subject: Re: [PATCH 4/4] mm: vmscan: If kswapd has been running too long, allow it to sleep References: <1305295404-12129-1-git-send-email-mgorman@suse.de> <1305295404-12129-5-git-send-email-mgorman@suse.de> <4DCFAA80.7040109@jp.fujitsu.com> <1305519711.4806.7.camel@mulgrave.site> <20110516084558.GE5279@suse.de> <20110516102753.GF5279@suse.de> <4DD31B6E.8040502@jp.fujitsu.com> In-Reply-To: Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org >>>>>> While it appears unlikely, there are bad conditions which can result >>>> >>>> in cond_resched() being avoided. >> >> Every reclaim priority decreasing or every shrink_zone() calling makes more >> fine grained preemption. I think. > > It could be. > But in direct reclaim case, I have a concern about losing pages > reclaimed to other tasks by preemption. Nope, I proposed to add cond_resched() into balance_pgdat(). > Hmm,, anyway, we also needs test. > Hmm,, how long should we bother them(Colins and James)? > First of all, Let's fix one just between us and ask test to them and > send the last patch to akpm. > > 1. shrink_slab > 2. right after balance_pgdat > 3. shrink_zone > 4. reclaim priority decreasing routine. > > Now, I vote 1) and 2). > > Mel, KOSAKI? I think following patch makes enough preemption. Thanks. From e7d88be1916184ea7c93a6f2746b15c7a32d1973 Mon Sep 17 00:00:00 2001 From: KOSAKI Motohiro Date: Wed, 18 May 2011 15:00:39 +0900 Subject: [PATCH] vmscan: balance_pgdat() call cond_resched() unconditionally Under constant allocation pressure, kswapd can be in the situation where sleeping_prematurely() will always return true even if kswapd has been running a long time. Check if kswapd needs to be scheduled. Signed-off-by: KOSAKI Motohiro Cc: Mel Gorman Cc: James Bottomley Cc: Colin King Cc: Minchan Kim --- mm/vmscan.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index 19e179b..87c88fd 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -2449,6 +2449,7 @@ loop_again: sc.nr_reclaimed += reclaim_state->reclaimed_slab; total_scanned += sc.nr_scanned; + cond_resched(); if (zone->all_unreclaimable) continue; if (nr_slab == 0 && @@ -2518,8 +2519,6 @@ out: * for the node to be balanced */ if (!(all_zones_ok || (order && pgdat_balanced(pgdat, balanced, *classzone_idx)))) { - cond_resched(); - try_to_freeze(); /*