From: Paul Menage on
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
> 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
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
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
* 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/