Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755473Ab1ERWzi (ORCPT ); Wed, 18 May 2011 18:55:38 -0400 Received: from mail-qy0-f174.google.com ([209.85.216.174]:37940 "EHLO mail-qy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754933Ab1ERWzg convert rfc822-to-8bit (ORCPT ); Wed, 18 May 2011 18:55:36 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FnwWCKw4hOxJ3LKNp9BhEcYKP1FJ4RXEb8wHaXQgwbmODpn0DDx/vWT6qsS3VVIgd6 ESTAFsEwBrgm4WFpymoUCeWigu4ixSq/nLWsMmf1UWgIkRnwni2/tO/5DAjutCVWyB+6 30+KLX2oWqQSQKVxiUmA+DIuWSckGq0G1LBMg= MIME-Version: 1.0 In-Reply-To: <20110518095859.GR5279@suse.de> References: <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> <20110518095859.GR5279@suse.de> Date: Thu, 19 May 2011 07:55:35 +0900 Message-ID: Subject: Re: [PATCH 4/4] mm: vmscan: If kswapd has been running too long, allow it to sleep From: Minchan Kim To: Mel Gorman Cc: KOSAKI Motohiro , 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2538 Lines: 70 On Wed, May 18, 2011 at 6:58 PM, Mel Gorman wrote: > On Wed, May 18, 2011 at 02:44:48PM +0900, Minchan Kim wrote: >> On Wed, May 18, 2011 at 10:05 AM, KOSAKI Motohiro >> wrote: >> >> 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. >> >> It could be. >> But in direct reclaim case, I have a concern about losing pages >> reclaimed to other tasks by preemption. >> >> 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). >> > > I've already submitted a pair of patches for option 1. I don't think > option 2 gains us anything. I think it's more likely we should worry > about all_unreclaimable being set when shrink_slab is returning 0 and we > are encountering so many dirty pages that pages_scanned is high enough. Okay. Colin reported he had no problem with patch 1 in this series and mine(ie, just cond_resched right after balance_pgdat call without no patch of shrink_slab). If Colin's test is successful, I don't insist on mine. (I don't want to drag on for days :( ) If KOSAKI agree, let's ask the test to Colin and confirm our last test. KOSAKI. Could you post a your opinion? -- Kind regards, Minchan Kim -- 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/