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: Balbir Singh on 13 May 2010 07:00 * Dhaval Giani <dhaval.giani(a)gmail.com> [2010-05-13 12:26: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 > Does something like cpusetinherits make more sense. -- 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: Peter Zijlstra on 13 May 2010 09:10 On Wed, 2010-05-12 at 21:07 +0200, Lennart Poettering wrote: > See Dhaval's patch on the background of systemd > (http://0pointer.de/blog/projects/systemd.html). When a service is > started in systemd, we create a cgroup for it, when it ends, we remove > it. I seriously hope that's optional, because I for one would really hate a system that does that. I still mostly build kernels with only cpuset in and really don't want anybody but me creating groups in there. -- 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: Lennart Poettering on 13 May 2010 10:10 On Thu, 13.05.10 15:01, Peter Zijlstra (peterz(a)infradead.org) wrote: > > On Wed, 2010-05-12 at 21:07 +0200, Lennart Poettering wrote: > > See Dhaval's patch on the background of systemd > > (http://0pointer.de/blog/projects/systemd.html). When a service is > > started in systemd, we create a cgroup for it, when it ends, we remove > > it. > > I seriously hope that's optional, because I for one would really hate a > system that does that. I still mostly build kernels with only cpuset in > and really don't want anybody but me creating groups in there. By default systemd will create its groups in the "debug" hierarchy, (at least for now, in the long run i'd like to see "noop" hierarchy or so, that doesn't sound so temporary), since that controller is not useful for anything but keeping track of processes. So it shouldn't bother you at all. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- 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 13 May 2010 16:10 On Thu, May 13, 2010 at 7:03 AM, Lennart Poettering <mzxreary(a)0pointer.de> wrote: > By default systemd will create its groups in the "debug" hierarchy, (at > least for now, in the long run i'd like to see "noop" hierarchy or so, > that doesn't sound so temporary), since that controller is not useful If you just want to track processes, mount a (named) hierarchy with no attached subsystems. 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: Dhaval Giani on 13 May 2010 16:20
On Thu, May 13, 2010 at 10:12 PM, Paul Menage <menage(a)google.com> wrote: > On Wed, May 12, 2010 at 12: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. >> > > Well, it's not clear to me whether the case I outlined is actually one > that would bite people - it's likely a rare case. > > Balbir's point that some apps might get upset by finding non-empty > mems/cpus in a newly-created cgroup is more reasonable. > > How about a per-cgroup cpuset.inherit_defaults file that defaults to > false and is inherited from the parent. If the parent's file is set to > true, then the mems/cpus are also inherited? > > Then the sysadmin who's giving out user-controllable cpuset-based > cgroups can just set it to true and the users don't need to worry > about setting up the defaults. > Default for root being "true" should work. Anything else, and you still require the programmer to know about cpuset and setting that flag to true. 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/ |