Messages in this thread | | | Date | Thu, 26 Feb 2009 17:09:38 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: [PATCH 0/4] cpuset: cleanups and fixes |
| |
On Thu, 26 Feb 2009 15:58:34 +0800 Li Zefan <lizf@cn.fujitsu.com> wrote:
> KAMEZAWA Hiroyuki wrote: > > On Thu, 26 Feb 2009 15:02:15 +0800 > > Li Zefan <lizf@cn.fujitsu.com> wrote: > > > >> This patchset mainly simplifies update_tasks_nodemask() and makes it > >> return void (won't fail), thus fix a case that writing to cpuset.mems > >> returns -ENOMEM but its mems_allowed has been changed. > >> > >> [PATCH 1/4] cgroups: add 'data' field to struct cgroup_scanner > >> [PATCH 2/4] cpuset: rewrite update_tasks_nodemask() > >> [PATCH 3/4] cpuset: avoid changing cpuset's mems when errno returned > >> [PATCH 4/4] cpuset: remove struct cpuset_hotplug_scanner > >> > > Thank you. I think there is no problematic in your patch. > > > > After reading your patch, I wonder we can improve this migration by > > filter for cgroup_scan_tasks(). > > > > Assume a task with tons of threads in a cgroup and > > - change nodemask > > - migrate=1 > > > > Under current implemntation, cpuset_migrate_mm=>do_migrate_mm is called per > > threads. This implies there will be big overhead, useless scanning of page > > tables. > > > > Can we add some checks as "Is this mm already migrated ?", anywhere ? > > (we may need to add some another array, again...) > > > > cpuset's memory_migrate flag is disabled by default, and I guess migrating mm > in cpuset is not frequently used? I tend to not optimise it unless it becomes > a problem in real-life. :) >
Ok, I will do by myself. -Kame
| |