From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751782AbZHaOgO (ORCPT ); Mon, 31 Aug 2009 10:36:14 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750734AbZHaOgO (ORCPT ); Mon, 31 Aug 2009 10:36:14 -0400 Received: from fgwmail7.fujitsu.co.jp ([192.51.44.37]:46661 "EHLO fgwmail7.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750712AbZHaOgN (ORCPT ); Mon, 31 Aug 2009 10:36:13 -0400 Message-ID: <641cca8561405679780a7afa4442e2a5.squirrel@webmail-b.css.fujitsu.com> In-Reply-To: <20090831122316.GM4770@balbir.in.ibm.com> References: <20090828132015.10a42e40.kamezawa.hiroyu@jp.fujitsu.com> <20090828132438.b33828bc.kamezawa.hiroyu@jp.fujitsu.com> <20090831110204.GG4770@balbir.in.ibm.com> <119e8331d1210b1f56d0f6416863bfbc.squirrel@webmail-b.css.fujitsu.com> <20090831121008.GL4770@balbir.in.ibm.com> <48d928bed22f20fc495e9ca1758dc7ed.squirrel@webmail-b.css.fujitsu.com> <20090831122316.GM4770@balbir.in.ibm.com> Date: Mon, 31 Aug 2009 23:36:12 +0900 (JST) Subject: Re: [RFC][PATCH 2/5] memcg: uncharge in batched manner From: "KAMEZAWA Hiroyuki" To: balbir@linux.vnet.ibm.com Cc: "KAMEZAWA Hiroyuki" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "nishimura@mxp.nes.nec.co.jp" User-Agent: SquirrelMail/1.4.16 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-2022-jp Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Balbir Singh wrote: > * KAMEZAWA Hiroyuki [2009-08-31 > 21:14:10]: > >> Balbir Singh wrote: >> >> > Does this effect deleting of a group and delay it by a large >> amount? >> >> > >> >> plz see what cgroup_release_and_xxxx fixed. This is not for delay >> >> but for race-condition, which makes rmdir sleep permanently. >> >> >> > >> > I've seen those patches, where rmdir() can hang. My conern was time >> > elapsed since we do css_get() and do a cgroup_release_and_wake_rmdir() >> > >> plz read unmap() and truncate() code. >> The number of pages handled without cond_resched() is limited. >> >> > > I understand that part, I was referring to tasks stuck doing rmdir() > while we do batched uncharge, will it be very visible to the end user? truncate/invalidate etc...is done in chunk of pagevec size. Now, it's 14. then, batched uncharge is done per 14 pages, IIUC. > cond_resched() is bad in this case.. since it means we'll stay longer > before we release the cgroup. cond_resched() is caller's matter. Not related memcg because we dont't call it. Thanks, -Kame > > > -- > Balbir >