LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Paul Menage" <menage@google.com>
To: "Andrew Morton" <akpm@linux-foundation.org>
Cc: containers@lists.osdl.org, linux-kernel@vger.kernel.org,
	balbir@linux.vnet.ibm.com, a.p.zijlstra@chello.nl,
	xemul@openvz.org, pj@sgi.com
Subject: Re: [RFC] Prefixing cgroup generic control filenames with "cgroup."
Date: Thu, 28 Feb 2008 14:06:30 -0800	[thread overview]
Message-ID: <6599ad830802281406t38e486d8g267df1873bc754c2@mail.gmail.com> (raw)
In-Reply-To: <20080228134027.05b2aa87.akpm@linux-foundation.org>

On Thu, Feb 28, 2008 at 1:40 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
>
>  Maybe cgroups shouldn't be putting kernel-generated files in places where
>  user-specified files appear?
>

Well, that API (mixing control files and group directories in the same
directory namespace) was inherited directly from cpusets.

It wouldn't be hard to throw that away and move all the user-created
group directories into their own subdirectory, i.e. change the
existing directory layout from something like:

/mnt/cgroup/
    tasks
    cpu.shares
    memory.limit_in_bytes
    memory.usage_in_bytes
    user_created_groupname1/
        tasks
        cpu.shares
        memory.limit_in_bytes
        memory.usage_in_bytes
    user_created_groupname2/
        tasks
        cpu.shares
        memory.limit_in_bytes
        memory.usage_in_bytes

to something like:

/mnt/cgroup/
    tasks
    cpu.shares
    memory.limit_in_bytes
    memory.usage_in_bytes
    groups/
        user_created_groupname1/
            tasks
            cpu.shares
            memory.limit_in_bytes
            memory.usage_in_bytes
            groups/
        user_created_groupname2/
            tasks
            cpu.shares
            memory.limit_in_bytes
            memory.usage_in_bytes
            groups/

That would completely solve the namespace problem, at the cost of a
little extra verbosity/inelegance for human users (I suspect
programmatic users would prefer it), and lack of compatibility with
2.6.24. I'd also need to make the existing model a mount option so
that we could keep compatibility with the cpusets filesystem API.

>  (Am still thrashing around a bit here without an overview of the overall
>  layout and naming).

Pretty much the same as cpusets, other than the additional
kernel-generated files in each directory, as provided by the resource
subsystems. So the same potential problem faced cpusets, but the fact
that new cpuset features weren't being developed quickly meant the
problem was less likely to actually bite people.

Paul

  reply	other threads:[~2008-02-28 22:06 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-28 21:14 Paul Menage
2008-02-28 21:21 ` Andrew Morton
2008-02-28 21:28   ` Paul Menage
2008-02-28 21:33     ` serge
2008-02-28 22:06       ` Paul Menage
2008-03-03  8:38         ` Paul Menage
2008-03-03  9:59           ` Balbir Singh
2008-02-28 21:40     ` Andrew Morton
2008-02-28 22:06       ` Paul Menage [this message]
2008-02-28 22:21         ` Andrew Morton
2008-02-28 22:26           ` Paul Menage
2008-02-29  5:59           ` [RFC] [PATCH] " Paul Menage
2008-02-29  6:20             ` Paul Jackson
2008-02-29  9:34               ` Paul Menage
2008-02-29 15:30                 ` Paul Jackson
2008-02-29 17:59                   ` Paul Menage
2008-02-29 19:20                     ` Paul Jackson
2008-02-28 21:28 ` [RFC] " serge
2008-02-28 23:36 ` Paul Jackson
2008-02-29  1:03   ` Paul Menage
2008-02-29  1:22     ` Paul Jackson
2008-02-29 11:38 ` Xpl++
2008-03-03  7:23   ` Li Zefan
2008-03-03  9:11     ` Paul Menage
2008-03-05  1:24     ` Paul Jackson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6599ad830802281406t38e486d8g267df1873bc754c2@mail.gmail.com \
    --to=menage@google.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=containers@lists.osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pj@sgi.com \
    --cc=xemul@openvz.org \
    --subject='Re: [RFC] Prefixing cgroup generic control filenames with "cgroup."' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).