Re: [PATCHSET] cpuset: decouple cpuset locking from cgroup core, take#2
On 2013/1/10 2:57, Tejun Heo wrote: > Hello, Li. > > On Tue, Jan 08, 2013 at 09:31:11AM +0800, Li Zefan wrote: >> I don't think Paul's still maintaining cpusets. Normally it's Andrew >> that picks up cpuset patches. It's fine you route it through cgroup >> tree. > > Can you please take over the cpuset maintainership then? I think you > would be the one most familiar with the code base at this point. > Sure, I'll send a patch to update MAINTAINERS. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET] cpuset: decouple cpuset locking from cgroup core, take#2
On Mon, Jan 7, 2013 at 5:31 PM, Li Zefan wrote: > > I don't think Paul's still maintaining cpusets. Normally it's Andrew > that picks up cpuset patches. It's fine you route it through cgroup > tree. Yes, I'm sorry - I should have handed on cpusets at the time I had to hand on cgroups. I was only really ever the maintainer for cpusets because Paul Jackson asked me to take it over when he retired, as I understood the cgroups-related parts of it. I never really had a good grasp of how the some of the lower-level parts of it interacted with the rest of the system (e.g. offlining, CPUs, scheduler domains, etc) anyway ... Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET] cpuset: decouple cpuset locking from cgroup core, take#2
Hello, Li. On Tue, Jan 08, 2013 at 09:31:11AM +0800, Li Zefan wrote: > I don't think Paul's still maintaining cpusets. Normally it's Andrew > that picks up cpuset patches. It's fine you route it through cgroup > tree. Can you please take over the cpuset maintainership then? I think you would be the one most familiar with the code base at this point. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET] cpuset: decouple cpuset locking from cgroup core, take#2
On 01/04/2013 01:35 AM, Tejun Heo wrote: > Note that this leaves memcg as the only external user of cgroup_mutex. > Michal, Kame, can you guys please convert memcg to use its own locking > too? I've already done this, I just have to rework it according to latest feedback and repost it. It should be in the open soon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET] cpuset: decouple cpuset locking from cgroup core, take#2
On 2013/1/8 0:44, Tejun Heo wrote: > Hello, Li. > > On Sun, Jan 06, 2013 at 04:27:00PM +0800, Li Zefan wrote: >> I've reviewed and tested the patchset, and it looks good to me! >> >> Acked-by: Li Zefan > > Great. Ummm... How should we route this? Paul doesn't seem to be > looking at this. I can route it through cgroup tree. Any objections? > I don't think Paul's still maintaining cpusets. Normally it's Andrew that picks up cpuset patches. It's fine you route it through cgroup tree. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET] cpuset: decouple cpuset locking from cgroup core, take#2
Hello, Li. On Sun, Jan 06, 2013 at 04:27:00PM +0800, Li Zefan wrote: > I've reviewed and tested the patchset, and it looks good to me! > > Acked-by: Li Zefan Great. Ummm... How should we route this? Paul doesn't seem to be looking at this. I can route it through cgroup tree. Any objections? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET] cpuset: decouple cpuset locking from cgroup core, take#2
(2013/01/04 6:35), Tejun Heo wrote: > Hello, guys. > > This is the second attempt at decoupling cpuset locking from cgroup > core. Changes from the last take[L] are > > * cpuset-drop-async_rebuild_sched_domains.patch moved from 0007 to >0009. This reordering makes cpu hotplug handling async first and >removes the temporary cyclic locking dependency. > > * 0006-cpuset-cleanup-cpuset-_can-_attach.patch no longer converts >cpumask_var_t to cpumask_t as per Rusty Russell. > > * 0008-cpuset-don-t-nest-cgroup_mutex-inside-get_online_cpu.patch now >synchronously rebuilds sched domains from cpu hotplug callback. >This fixes various issues caused by confused scheduler puttings >tasks into a dead cpu including the RCU stall problem reported by Li >Zefan. > > Original patchset description follows. > > Depending on cgroup core locking - cgroup_mutex - is messy and makes > cgroup prone to locking dependency problems. The current code already > has lock dependency loop - memcg nests get_online_cpus() inside > cgroup_mutex. cpuset the other way around. > > Regardless of the locking details, whatever is protecting cgroup has > inherently to be something outer to most other locking constructs. > cgroup calls into a lot of major subsystems which in turn have to > perform subsystem-specific locking. Trying to nest cgroup > synchronization inside other locks isn't something which can work > well. > > cgroup now has enough API to allow subsystems to implement their own > locking and cgroup_mutex is scheduled to be made private to cgroup > core. This patchset makes cpuset implement its own locking instead of > relying on cgroup_mutex. > > cpuset is rather nasty in this respect. Some of it seems to have come > from the implementation history - cgroup core grew out of cpuset - but > big part stems from cpuset's need to migrate tasks to an ancestor > cgroup when an hotunplug event makes a cpuset empty (w/o any cpu or > memory). > > This patchset decouples cpuset locking from cgroup_mutex. After the > patchset, cpuset uses cpuset-specific cpuset_mutex instead of > cgroup_mutex. This also removes the lockdep warning triggered during > cpu offlining (see 0009). > > Note that this leaves memcg as the only external user of cgroup_mutex. > Michal, Kame, can you guys please convert memcg to use its own locking > too? > Okay...but If Costa has a new version of his patch, I'd like to see it. I'm sorry if I missed his new patches for removing cgroup_lock. Thanks, -Kame Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET] cpuset: decouple cpuset locking from cgroup core, take#2
On 2013/1/4 5:35, Tejun Heo wrote: > Hello, guys. > > This is the second attempt at decoupling cpuset locking from cgroup > core. Changes from the last take[L] are > > * cpuset-drop-async_rebuild_sched_domains.patch moved from 0007 to > 0009. This reordering makes cpu hotplug handling async first and > removes the temporary cyclic locking dependency. > > * 0006-cpuset-cleanup-cpuset-_can-_attach.patch no longer converts > cpumask_var_t to cpumask_t as per Rusty Russell. > > * 0008-cpuset-don-t-nest-cgroup_mutex-inside-get_online_cpu.patch now > synchronously rebuilds sched domains from cpu hotplug callback. > This fixes various issues caused by confused scheduler puttings > tasks into a dead cpu including the RCU stall problem reported by Li > Zefan. > > Original patchset description follows. > > Depending on cgroup core locking - cgroup_mutex - is messy and makes > cgroup prone to locking dependency problems. The current code already > has lock dependency loop - memcg nests get_online_cpus() inside > cgroup_mutex. cpuset the other way around. > > Regardless of the locking details, whatever is protecting cgroup has > inherently to be something outer to most other locking constructs. > cgroup calls into a lot of major subsystems which in turn have to > perform subsystem-specific locking. Trying to nest cgroup > synchronization inside other locks isn't something which can work > well. > > cgroup now has enough API to allow subsystems to implement their own > locking and cgroup_mutex is scheduled to be made private to cgroup > core. This patchset makes cpuset implement its own locking instead of > relying on cgroup_mutex. > > cpuset is rather nasty in this respect. Some of it seems to have come > from the implementation history - cgroup core grew out of cpuset - but > big part stems from cpuset's need to migrate tasks to an ancestor > cgroup when an hotunplug event makes a cpuset empty (w/o any cpu or > memory). > > This patchset decouples cpuset locking from cgroup_mutex. After the > patchset, cpuset uses cpuset-specific cpuset_mutex instead of > cgroup_mutex. This also removes the lockdep warning triggered during > cpu offlining (see 0009). > > Note that this leaves memcg as the only external user of cgroup_mutex. > Michal, Kame, can you guys please convert memcg to use its own locking > too? > > This patchset contains the following thirteen patches. > > 0001-cpuset-remove-unused-cpuset_unlock.patch > 0002-cpuset-remove-fast-exit-path-from-remove_tasks_in_em.patch > 0003-cpuset-introduce-css_on-offline.patch > 0004-cpuset-introduce-CS_ONLINE.patch > 0005-cpuset-introduce-cpuset_for_each_child.patch > 0006-cpuset-cleanup-cpuset-_can-_attach.patch > 0007-cpuset-reorganize-CPU-memory-hotplug-handling.patch > 0008-cpuset-don-t-nest-cgroup_mutex-inside-get_online_cpu.patch > 0009-cpuset-drop-async_rebuild_sched_domains.patch > 0010-cpuset-make-CPU-memory-hotplug-propagation-asynchron.patch > 0011-cpuset-pin-down-cpus-and-mems-while-a-task-is-being-.patch > 0012-cpuset-schedule-hotplug-propagation-from-cpuset_atta.patch > 0013-cpuset-replace-cgroup_mutex-locking-with-cpuset-inte.patch > > 0001-0006 are prep patches. > > 0007-0009 make cpuset nest get_online_cpus() inside cgroup_mutex, not > the other way around. > > 0010-0012 plug holes which would be exposed by switching to > cpuset-specific locking. > > 0013 replaces cgroup_mutex with cpuset_mutex. > > This patchset is on top of v3.8-rc2 (d1c3ed669a) and also available in > the following git branch. > > git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git > review-cpuset-locking > > diffstat follows. > > kernel/cpuset.c | 760 > > 1 file changed, 438 insertions(+), 322 deletions(-) I've reviewed and tested the patchset, and it looks good to me! Acked-by: Li Zefan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHSET] cpuset: decouple cpuset locking from cgroup core, take#2
Hello, guys. This is the second attempt at decoupling cpuset locking from cgroup core. Changes from the last take[L] are * cpuset-drop-async_rebuild_sched_domains.patch moved from 0007 to 0009. This reordering makes cpu hotplug handling async first and removes the temporary cyclic locking dependency. * 0006-cpuset-cleanup-cpuset-_can-_attach.patch no longer converts cpumask_var_t to cpumask_t as per Rusty Russell. * 0008-cpuset-don-t-nest-cgroup_mutex-inside-get_online_cpu.patch now synchronously rebuilds sched domains from cpu hotplug callback. This fixes various issues caused by confused scheduler puttings tasks into a dead cpu including the RCU stall problem reported by Li Zefan. Original patchset description follows. Depending on cgroup core locking - cgroup_mutex - is messy and makes cgroup prone to locking dependency problems. The current code already has lock dependency loop - memcg nests get_online_cpus() inside cgroup_mutex. cpuset the other way around. Regardless of the locking details, whatever is protecting cgroup has inherently to be something outer to most other locking constructs. cgroup calls into a lot of major subsystems which in turn have to perform subsystem-specific locking. Trying to nest cgroup synchronization inside other locks isn't something which can work well. cgroup now has enough API to allow subsystems to implement their own locking and cgroup_mutex is scheduled to be made private to cgroup core. This patchset makes cpuset implement its own locking instead of relying on cgroup_mutex. cpuset is rather nasty in this respect. Some of it seems to have come from the implementation history - cgroup core grew out of cpuset - but big part stems from cpuset's need to migrate tasks to an ancestor cgroup when an hotunplug event makes a cpuset empty (w/o any cpu or memory). This patchset decouples cpuset locking from cgroup_mutex. After the patchset, cpuset uses cpuset-specific cpuset_mutex instead of cgroup_mutex. This also removes the lockdep warning triggered during cpu offlining (see 0009). Note that this leaves memcg as the only external user of cgroup_mutex. Michal, Kame, can you guys please convert memcg to use its own locking too? This patchset contains the following thirteen patches. 0001-cpuset-remove-unused-cpuset_unlock.patch 0002-cpuset-remove-fast-exit-path-from-remove_tasks_in_em.patch 0003-cpuset-introduce-css_on-offline.patch 0004-cpuset-introduce-CS_ONLINE.patch 0005-cpuset-introduce-cpuset_for_each_child.patch 0006-cpuset-cleanup-cpuset-_can-_attach.patch 0007-cpuset-reorganize-CPU-memory-hotplug-handling.patch 0008-cpuset-don-t-nest-cgroup_mutex-inside-get_online_cpu.patch 0009-cpuset-drop-async_rebuild_sched_domains.patch 0010-cpuset-make-CPU-memory-hotplug-propagation-asynchron.patch 0011-cpuset-pin-down-cpus-and-mems-while-a-task-is-being-.patch 0012-cpuset-schedule-hotplug-propagation-from-cpuset_atta.patch 0013-cpuset-replace-cgroup_mutex-locking-with-cpuset-inte.patch 0001-0006 are prep patches. 0007-0009 make cpuset nest get_online_cpus() inside cgroup_mutex, not the other way around. 0010-0012 plug holes which would be exposed by switching to cpuset-specific locking. 0013 replaces cgroup_mutex with cpuset_mutex. This patchset is on top of v3.8-rc2 (d1c3ed669a) and also available in the following git branch. git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git review-cpuset-locking diffstat follows. kernel/cpuset.c | 760 1 file changed, 438 insertions(+), 322 deletions(-) Thanks. -- tejun [L] http://thread.gmane.org/gmane.linux.kernel.cgroups/5251 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
