Messages in this thread | ![/](/images/icornerl.gif) | | Date | Fri, 16 Mar 2007 07:10:24 +0530 | From | Srivatsa Vaddagiri <> | Subject | Re: Summary of resource management discussion |
| |
On Thu, Mar 15, 2007 at 12:12:50PM -0700, Paul Menage wrote: > There are some things that benefit from having an abstract > container-like object available to store state, e.g. "is this > container deleted?", "should userspace get a callback when this > container is empty?".
IMO we can still get these bits of information using nsproxy itself (I admit I haven't looked at the callback requirement yet).
But IMO a bigger use of 'struct container' object in your patches is to store hierarchical information and avoid /repeating/ that information in each resource object (struct cpuset, struct cpu_limit, struct rss_limit etc) a 'struct container' is attached to (as pointed out here : http://lkml.org/lkml/2007/3/7/356). However I don't know how many controllers will ever support such hierarchical res mgmt and thats why I said option 3 [above URL] may not be a bad compromise.
Also if you find a good answer for my earlier question "what more task-grouping behavior do you want to implement using an additional pointer that you can't reusing ->task_proxy", it would drive home the need for additional pointers/structures.
> >> >a. Paul Menage's patches: > >> > > >> > (tsk->containers->container[cpu_ctlr.subsys_id] - X)->cpu_limit > >> > >> So what's the '-X' that you're referring to > > > >Oh ..that's to seek pointer to begining of the cpulimit structure (subsys > >pointer in 'struct container' points to a structure embedded in a larger > >structure. -X gets you to point to the larger structure). > > OK, so shouldn't that be listed as an overhead for your rcfs version > too?
X shouldn't be needed in rcfs patches, because "->ctlr_data" in nsproxy can directly point to the larger structure (there is no 'struct container_subsys_state' equivalent in rcfs patches).
Container patches:
(tsk->containers->container[cpu_ctlr.subsys_id] - X)->cpu_limit
rcfs:
tsk->nsproxy->ctlr_data[cpu_ctlr.subsys_id]->cpu_limit
> >Yes me too. But maybe to keep in simple in initial versions, we should > >avoid that optimisation and at the same time get statistics on duplicates?. > > That's an implementation detail - we have more important points to > agree on right now ...
yes :)
Eric, did you have any opinion on this thread?
-- Regards, vatsa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |