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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.