Have sane default values for cpusets
in [Kernel]
|
Prev: [PATCH] remove bogus #ifdef CONFIG_TRACE_IRQFLAGS_SUPPORT for debug_kmap_atomic()
Next: [pm] resume from s3 oops? (last checked on rc6)
From: Paul Menage on 12 May 2010 15:30 On Wed, May 12, 2010 at 12:10 PM, Dhaval Giani <dhaval.giani(a)gmail.com> wrote: > On Wed, May 12, 2010 at 9:01 PM, Paul Menage <menage(a)google.com> wrote: >> What about the case where some subset of the parent's mems/cpus are >> given to a child with the exclusive flag set? >> > > As I mentioned in the TODO, it is still to be handled. Oops, sorry, just read the patch :-) > But it should > simply exclude those mems/cpus which are exclusive. It was a bit more > involved than the effort I wanted to put in before gauging the > reactions. I think the idea is reasonable - the only way that I could see it breaking someone would be code that currently does something like: mkdir A mkdir B echo 1 > A/mem_exclusive echo 1 > B/mem_exclusive echo $mems_for_a > A/mems echo $mems_for_b > B/mems The attempts to set the mem_exclusive flags would fail, since A and B would both have all of the parent's mems. Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Paul Menage on 12 May 2010 15:40 On Wed, May 12, 2010 at 12:29 PM, Dhaval Giani <dhaval.giani(a)gmail.com> wrote: >> I think the idea is reasonable - the only way that I could see it >> breaking someone would be code that currently does something like: >> >> mkdir A >> mkdir B >> echo 1 > A/mem_exclusive >> echo 1 > B/mem_exclusive >> echo $mems_for_a > A/mems >> echo $mems_for_b > B/mems >> >> The attempts to set the mem_exclusive flags would fail, since A and B >> would both have all of the parent's mems. >> > > But would this not fail otherwise? > Assuming that mems_for_a and mems_for_b were disjoint, it would be fine currently. Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Balbir Singh on 12 May 2010 15:40 * Dhaval Giani <dhaval.giani(a)gmail.com> [2010-05-12 15:05:41]: > Hi folks, > > This does not break ABI since applications which were explicitly setting > up the cpusets will still be setting them up anyway. And if someone was > checking if a cpuset was setup or not by checking the state of > cpuset.cpus_allowed, then it was broken and should be fixed. > The only ABI breakage I would consider is A user space application reading those values and expecting them to be empty before taking any action -- Three Cheers, Balbir -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dhaval Giani on 12 May 2010 16:00 On Wed, May 12, 2010 at 9:36 PM, Paul Menage <menage(a)google.com> wrote: > On Wed, May 12, 2010 at 12:29 PM, Dhaval Giani <dhaval.giani(a)gmail.com> wrote: >>> I think the idea is reasonable - the only way that I could see it >>> breaking someone would be code that currently does something like: >>> >>> mkdir A >>> mkdir B >>> echo 1 > A/mem_exclusive >>> echo 1 > B/mem_exclusive >>> echo $mems_for_a > A/mems >>> echo $mems_for_b > B/mems >>> >>> The attempts to set the mem_exclusive flags would fail, since A and B >>> would both have all of the parent's mems. >>> >> >> But would this not fail otherwise? >> > > Assuming that mems_for_a and mems_for_b were disjoint, it would be > fine currently. > Ah my bad. I misread mems_for_a as taking the value from the parent. You are right, that was a case I missed. Hmm, so how do we fix this? Any solutions? Not fixing the kernel pushes the problem to the userspace, making it hard for tons of more applications to use cgroups without jumping through a lot of hoops. Dhaval -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dhaval Giani on 13 May 2010 06:30
On Wed, May 12, 2010 at 9:59 PM, Dhaval Giani <dhaval.giani(a)gmail.com> wrote: > On Wed, May 12, 2010 at 9:36 PM, Paul Menage <menage(a)google.com> wrote: >> On Wed, May 12, 2010 at 12:29 PM, Dhaval Giani <dhaval.giani(a)gmail.com> wrote: >>>> I think the idea is reasonable - the only way that I could see it >>>> breaking someone would be code that currently does something like: >>>> >>>> mkdir A >>>> mkdir B >>>> echo 1 > A/mem_exclusive >>>> echo 1 > B/mem_exclusive >>>> echo $mems_for_a > A/mems >>>> echo $mems_for_b > B/mems >>>> >>>> The attempts to set the mem_exclusive flags would fail, since A and B >>>> would both have all of the parent's mems. >>>> >>> >>> But would this not fail otherwise? >>> >> >> Assuming that mems_for_a and mems_for_b were disjoint, it would be >> fine currently. >> > > Ah my bad. I misread mems_for_a as taking the value from the parent. > You are right, that was a case I missed. > > Hmm, so how do we fix this? Any solutions? Not fixing the kernel > pushes the problem to the userspace, making it hard for tons of more > applications to use cgroups without jumping through a lot of hoops. > OK, how about this. Introduce a new option, nodefaults (or some such name) which would retain the existing behaviour while the default mount options would moutn cpuset with the defaults. Also, make mount -t cpuset cpuset /cpuset equivalent to mount -t cgroup -onoprefix,nodefaults,cpuset cpuset /cpuset Would that work? Thanks, Dhaval -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |