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 13 May 2010 16:20 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. 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:30 > 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. > To be honest, I don't see an easy way out of this. I think it is more reasonable to have the change since a lot more users are benefited by it. And in most cases, where they are broken, those applications do require some specialist work, and so it should be reasonable to expect the administrator to set the variable to false at mount time. 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: Lennart Poettering on 13 May 2010 16:40 On Thu, 13.05.10 13:06, Paul Menage (menage(a)google.com) wrote: > > 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. Oh, that is possible? How would I do that? This certainly doesn't work: # mount waldo -t cgroup /tmp/xxxx -o defaults 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: Lennart Poettering on 13 May 2010 16:50 On Thu, 13.05.10 22:36, Lennart Poettering (mzxreary(a)0pointer.de) wrote: > On Thu, 13.05.10 13:06, Paul Menage (menage(a)google.com) wrote: > > > > > 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. > > Oh, that is possible? How would I do that? > > This certainly doesn't work: > > # mount waldo -t cgroup /tmp/xxxx -o defaults An neither does this: # mount waldo -t cgroup /tmp/xxxx -o name=systemd (the mount() syscall fails with EINVAL here, the other one fails with EBUSY) 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: Balbir Singh on 13 May 2010 17:10
* Lennart Poettering <mzxreary(a)0pointer.de> [2010-05-13 22:41:59]: > On Thu, 13.05.10 22:36, Lennart Poettering (mzxreary(a)0pointer.de) wrote: > > > On Thu, 13.05.10 13:06, Paul Menage (menage(a)google.com) wrote: > > > > > > > > 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. > > > > Oh, that is possible? How would I do that? > > > > This certainly doesn't work: > > > > # mount waldo -t cgroup /tmp/xxxx -o defaults > > An neither does this: > > # mount waldo -t cgroup /tmp/xxxx -o name=systemd > > (the mount() syscall fails with EINVAL here, the other one fails with EBUSY) > Can you try the command below mount -t cgroup cgroup -o none,name=hello /cgroup/ Works for me. -- 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/ |