From: Srivatsa Vaddagiri <vatsa@in.ibm.com>
To: menage@google.com
Cc: akpm@linux-foundation.org, sekharan@us.ibm.com, dev@sw.ru,
xemul@sw.ru, serue@us.ibm.com, ebiederm@xmission.com,
ckrm-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org,
containers@lists.osdl.org, mbligh@google.com,
rohitseth@google.com, devel@openvz.org
Subject: Re: [PATCH 3/7] Containers (V8): Add generic multi-subsystem API to containers
Date: Wed, 11 Apr 2007 22:12:53 +0530 [thread overview]
Message-ID: <20070411164253.GA26228@in.ibm.com> (raw)
In-Reply-To: <20070407001324.271959000@menage.corp.google.com>
Coming from a "simplify things" pov:
On Fri, Apr 06, 2007 at 04:32:24PM -0700, menage@google.com wrote:
> struct container {
> unsigned long flags; /* "unsigned long" so bitops work */
>
> /*
> - * Count is atomic so can incr (fork) or decr (exit) without a lock.
> - */
> - atomic_t count; /* count tasks using this container */
> -
> - /*
> * We link our 'sibling' struct into our parent's 'children'.
> * Our children link their 'sibling' into our 'children'.
> */
> @@ -43,11 +106,13 @@ struct container {
> struct list_head children; /* my children */
>
> struct container *parent; /* my parent */
> - struct dentry *dentry; /* container fs entry */
> + struct dentry *dentry; /* container fs entry */
>
> -#ifdef CONFIG_CPUSETS
> - struct cpuset *cpuset;
> -#endif
> + /* Private pointers for each registered subsystem */
> + struct container_subsys_state *subsys[CONTAINER_SUBSYS_COUNT];
> +
> + struct containerfs_root *root;
Could this root pointer derived from dentry pointer
(cont->dentry->d_sb->s_fs_info)?
> + struct container *top_container;
and this as well?
cont->dentry->d_sb->s_fs_info->top_container
> };
So we have the foward subsys pointer array being stored in both
'struct container' and 'struct container_group' and reverse container pointer
stored in struct container_subsys_state. Can we reduce this pointer maze by:
struct container {
/* All shared stuff like flags, parent/child pointers etc */
..
struct container_group *my_group;
}
The forward mapping from 'struct container' to subsys objects is made via
'my_group'. This also lets 'struct container' be a placeholder strictly for
shared state.
On further thoughts, perhaps even my_group can be avoided by having:
dentry->d_fsdata point to my_group
and cont->dentry->d_fsdata will point to my_group which we wanted to store
above.
I don't see distinct adv of doing this, but I suspect it will simplify
the structure relationship (and code) a bit.
--
Regards,
vatsa
next prev parent reply other threads:[~2007-04-11 16:35 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-06 23:32 [PATCH 0/7] Containers (V8): Generic Process Containers menage
2007-04-06 23:32 ` [PATCH 1/7] Containers (V8): Generic container system abstracted from cpusets code menage
2007-04-06 23:32 ` [PATCH 2/7] Containers (V8): Cpusets hooked into containers menage
2007-04-23 10:52 ` Vaidyanathan Srinivasan
2007-04-25 4:59 ` Paul Menage
2007-04-06 23:32 ` [PATCH 4/7] Containers (V8): Simple CPU accounting container subsystem menage
2007-04-10 13:16 ` Srivatsa Vaddagiri
2007-04-06 23:32 ` [PATCH 5/7] Containers (V8): Resource Groups over generic containers menage
2007-04-06 23:32 ` [PATCH 6/7] Containers (V8): BeanCounters over generic process containers menage
2007-04-09 7:46 ` Pavel Emelianov
2007-04-09 16:44 ` William Lee Irwin III
2007-04-06 23:32 ` [PATCH 7/7] Containers (V8): Container interface to nsproxy subsystem menage
[not found] ` <20070407001324.271959000@menage.corp.google.com>
2007-04-07 1:58 ` [ckrm-tech] [PATCH 3/7] Containers (V8): Add generic multi-subsystem API to containers Paul Menage
2007-04-07 4:18 ` Srivatsa Vaddagiri
2007-04-07 17:30 ` Paul Menage
2007-04-10 14:42 ` Srivatsa Vaddagiri
2007-04-10 14:52 ` Srivatsa Vaddagiri
2007-04-10 15:45 ` [ckrm-tech] " Paul Menage
2007-04-11 4:47 ` Srivatsa Vaddagiri
2007-04-11 5:01 ` Srivatsa Vaddagiri
2007-04-11 8:42 ` Paul Menage
2007-04-11 16:42 ` Srivatsa Vaddagiri [this message]
2007-04-23 11:07 ` [PATCH 0/7] Containers (V8): Generic Process Containers Vaidyanathan Srinivasan
2007-04-25 5:04 ` [ckrm-tech] " 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=20070411164253.GA26228@in.ibm.com \
--to=vatsa@in.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=ckrm-tech@lists.sourceforge.net \
--cc=containers@lists.osdl.org \
--cc=dev@sw.ru \
--cc=devel@openvz.org \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@google.com \
--cc=menage@google.com \
--cc=rohitseth@google.com \
--cc=sekharan@us.ibm.com \
--cc=serue@us.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