linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Lennart Poettering <lpoetter@redhat.com>
Cc: Tejun Heo <tj@kernel.org>,
	aris@redhat.com, linux-kernel@vger.kernel.org,
	cgroups@vger.kernel.org, Li Zefan <lizefan@huawei.com>,
	Hugh Dickins <hughd@google.com>, Hillf Danton <dhillf@gmail.com>
Subject: Re: [PATCH v6 3/4] cgroup: add xattr support
Date: Thu, 23 Aug 2012 17:02:34 -0700	[thread overview]
Message-ID: <87ipc9kvhh.fsf@xmission.com> (raw)
In-Reply-To: <50340110.50607@redhat.com> (Lennart Poettering's message of "Tue, 21 Aug 2012 23:43:44 +0200")

Lennart Poettering <lpoetter@redhat.com> writes:

> Heya,
>
> (sorry for the late reply)
>
> On 16.08.2012 22:00, Tejun Heo wrote:
>> On Thu, Aug 16, 2012 at 01:44:56PM -0400, aris@redhat.com wrote:
>
>>>> Attaching meta information to services, in an easily discoverable
>>>> way. For example, in systemd we create one cgroup for each service, and
>>>> could then store data like the main pid of the specific service as an
>>>> xattr on the cgroup itself. That way we'd have almost all service state
>>>> in the cgroupfs, which would make it possible to terminate systemd and
>>>> later restart it without losing any state information. But there's more:
>>>> for example, some very peculiar services cannot be terminated on
>>>> shutdown (i.e. fakeraid DM stuff) and it would be really nice if the
>>>> services in question could just mark that on their cgroup, by setting an
>>>> xattr. On the more desktopy side of things there are other
>>>> possibilities: for example there are plans defining what an application
>>>> is along the lines of a cgroup (i.e. an app being a collection of
>>>> processes). With xattrs one could then attach an icon or human readable
>>>> program name on the cgroup.
>>>>
>>>> The key idea is that this would allow attaching runtime meta information
>>>> to cgroups and everything they model (services, apps, vms), that doesn't
>>>> need any complex userspace infrastructure, has good access control
>>>> (i.e. because the file system enforces that anyway, and there's the
>>>> "trusted." xattr namespace), notifications (inotify), and can easily be
>>>> shared among applications.
>
>>
>> I'm not against this but unsure whether using kmem is enough for the
>> suggested use case.  Lennart, would this suit systemd?  How much
>> metadata are we talking about?
>
> Just small things, like values, PIDs, i.e. a few 100 bytes or so per cgroup
> should be more than sufficient for our needs.

I have a really silly question.  Why is storing these things in xattrs
in a cgroup better than simply implementing a file in a cgroup?

It is most definitely going to be a real pain to discover as unix tools
do not support xattrs well.

Furthermore I am having nasty visiions that storing pids is going to
start breaking cgroups the way storing pids already breaks futexes.
Which pid namespace is that pid relative to?

Eric

  parent reply	other threads:[~2012-08-24  0:02 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-16 17:44 [PATCH v6 0/4] cgroup: add xattr support aris
2012-08-16 17:44 ` [PATCH v6 1/4] xattr: extract simple_xattr code from tmpfs aris
2012-08-16 19:58   ` Tejun Heo
2012-08-20  7:10     ` Hugh Dickins
2012-08-20 19:00       ` Aristeu Rozanski
2012-08-21  4:47         ` Hugh Dickins
2012-08-22 20:07           ` Aristeu Rozanski
2012-08-22 20:25             ` Hugh Dickins
2012-08-22 20:55               ` Aristeu Rozanski
2012-08-16 17:44 ` [PATCH v6 2/4] cgroup: revise how we re-populate root directory aris
2012-08-16 17:44 ` [PATCH v6 3/4] cgroup: add xattr support aris
2012-08-16 20:00   ` Tejun Heo
2012-08-21 21:43     ` Lennart Poettering
2012-08-21 21:48       ` Tejun Heo
2012-08-21 23:29         ` Hugh Dickins
2012-08-23 19:44           ` Tejun Heo
2012-08-23 19:58             ` Aristeu Rozanski
2012-08-24  0:02       ` Eric W. Biederman [this message]
2012-08-16 17:44 ` [PATCH v6 4/4] cgroup: rename subsys_bits to subsys_mask aris

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=87ipc9kvhh.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=aris@redhat.com \
    --cc=cgroups@vger.kernel.org \
    --cc=dhillf@gmail.com \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=lpoetter@redhat.com \
    --cc=tj@kernel.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).