Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932666Ab1ERBGM (ORCPT ); Tue, 17 May 2011 21:06:12 -0400 Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]:58067 "EHLO fgwmail6.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932082Ab1ERBGK (ORCPT ); Tue, 17 May 2011 21:06:10 -0400 X-SecurityPolicyCheck-FJ: OK by FujitsuOutboundMailChecker v1.3.1 Message-ID: <4DD31B6E.8040502@jp.fujitsu.com> Date: Wed, 18 May 2011 10:05:50 +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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 984 Lines: 27 > It would be better to put cond_resched after balance_pgdat? > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 292582c..61c45d0 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -2753,6 +2753,7 @@ static int kswapd(void *p) > if (!ret) { > trace_mm_vmscan_kswapd_wake(pgdat->node_id, order); > order = balance_pgdat(pgdat, order,&classzone_idx); > + cond_resched(); > } > } > return 0; > >>>> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/