From: Minchan Kim Subject: Re: [PATCH 4/4] mm: vmscan: If kswapd has been running too long, allow it to sleep Date: Thu, 19 May 2011 07:55:35 +0900 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 To: Mel Gorman Return-path: In-Reply-To: <20110518095859.GR5279@suse.de> Sender: owner-linux-mm@kvack.org List-Id: linux-ext4.vger.kernel.org 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) >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!ret) { >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 trace_mm_vmscan_kswapd_wake(pgdat->node_id, >> >> order); >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 order =3D balance_pgdat(pgdat, >> >> order,&classzone_idx); >> >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 cond_resched(); >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 } >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 return 0; >> >> >> >>>>> While it appears unlikely, there are bad conditions which can resu= lt >> >>> >> >>> 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? --=20 Kind regards, Minchan Kim -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org