From: "Paul Menage" <menage@google.com>
To: "Balbir Singh" <balbir@linux.vnet.ibm.com>
Cc: vatsa@in.ibm.com, linux-kernel@vger.kernel.org, xemul@sw.ru,
dev@sw.ru, akpm@linux-foundation.org, devel@openvz.org
Subject: Re: [RFC][PATCH] Per container statistics
Date: Mon, 21 May 2007 13:56:31 -0700 [thread overview]
Message-ID: <6599ad830705211356l9f2d24jc3a7834e7db34458@mail.gmail.com> (raw)
In-Reply-To: <20070514174454.15338.67171.sendpatchset@balbir-laptop>
Hi Balbir,
On 5/14/07, Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
>
> This patch implements per container statistics infrastructure and re-uses
> code from the taskstats interface. A new set of container operations are
> registered with commands and attributes. It should be very easy to
> extend per container statistics, by adding members to the containerstats
> structure.
Sorry for the delay in looking at this. (I've been travelling a bit).
The basic idea of being able to get stats on a per-container basis
seems good, but I've got some suggestions on the API/implementation:
- saving a mount pointer in the containerfsroot structure won't work
because a hierarchy (superblock) can be mounted in more than one
place, or even in zero places (if you unmount a hierarchy with active
containers, the superblock and the containers stay active). Also it
might be possible to move a mounted container hierarchy via mount
--move, although I've not actually tried that.
- a cleaner way to pass in a container id would be to pass a file
descriptor on a container directory. The dentry associated with this
fd would unambiguously identify the hierarchy and the container, so
then even if we didn't maintain a per-container task likst, the
for_each_thread() loop would involve just a single comparison per task
to see if the task was in the desired container.
- if we're trying to integrate this with taskstats, then it would be
nice to support retrieving all the other taskstats values (where they
make sense) on a per-container basis (in the same way that we can
currently request them on a per-thread or a per-process basis). i.e.
don't create a new container_taskstats structure, but instead augment
the current taskstats structure, and allow the user to retrieve the
aggregate of that for the entire container. Similarly, being able to
get taskstats notifications based on the container memberships of a
task might be nice.
Paul
next prev parent reply other threads:[~2007-05-21 20:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-14 17:44 Balbir Singh
2007-05-15 7:12 ` Kirill Korotaev
2007-05-15 7:23 ` Balbir Singh
2007-05-21 20:56 ` Paul Menage [this message]
2007-05-24 15:59 ` Balbir Singh
2007-05-24 16:12 ` Paul Menage
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=6599ad830705211356l9f2d24jc3a7834e7db34458@mail.gmail.com \
--to=menage@google.com \
--cc=akpm@linux-foundation.org \
--cc=balbir@linux.vnet.ibm.com \
--cc=dev@sw.ru \
--cc=devel@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vatsa@in.ibm.com \
--cc=xemul@sw.ru \
/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
all inboxes | Powered by JetHome®