Messages in this thread |  | | | Date | Mon, 31 Aug 2009 23:36:12 +0900 (JST) | | Subject | Re: [RFC][PATCH 2/5] memcg: uncharge in batched manner | | From | "KAMEZAWA Hiroyuki" <> |
| |
Balbir Singh wrote: > * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [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 >
|  |