Messages in this thread | | | Subject | Re: [ckrm-tech] [RFC] [PATCH 00/12] CKRM after a major overhaul | From | Matt Helsley <> | Date | Sat, 22 Apr 2006 19:33:42 -0700 |
| |
On Sat, 2006-04-22 at 23:40 +0300, Al Boldi wrote: > Chandra Seetharaman wrote: > > On Sat, 2006-04-22 at 07:08 +0300, Al Boldi wrote: > > > i.e: it should be possible to run the RCs w/o CKRM. > > > > > > The current design pins the RCs on CKRM, when in fact this is not > > > necessary. One way to decouple them, could be to pin them against pid, > > > thus allowing an RC to leverage the pid hierarchy w/o the need for CKRM. > > > And only when finer RM control is necessary, should CKRM come into > > > play, by dynamically adjusting the RC to achieve the desired effect. > > > > This model works well in universities, where you associate some resource > > when a student logs in, or a virtualised environment (like a UML or > > vserver), where you attach resource to the root process. > > > > It doesn't work with web servers, database servers etc.,, where the main > > application will be forking tasks for different set of end users. In > > that case you have to group tasks that are not related to one another > > and attach resources to them. > > > > Having a unified interface gives the system administrator ability to > > group the tasks as they see them in real life (a department or important > > transactions or just critical apps in a desktop). > > So, why drag this unified interface around when it is only needed in certain > models. The underlying interface via pid comes for free and should be > leveraged as such to yield a low overhead implementation. Then maybe, when > a more complex model is involved should CKRM come into play.
Assuming I'm not misinterpretting your brief description above:
The interface "via pid" does not come for free. You'd essentially attach the shares structures to the task and implement inheritance and hierarchy of those shares during fork -- hardly lower overhead when you consider that in most cases the number of tasks is going to be much larger than the number of classes. Furthermore this would mean duplicating the loops in ckrm_alloc_class, ckrm_free_class, ckrm_register_controller, and ckrm_unregister_controller. I suspect the loops would be deeper, more complex, execute more frequently, and have a much wider performance impact when you consider that we'd be dealing with the task struct directly instead of a class. The class structure effectively factors most of the loops out of the fork() and exit() paths and into mkdir() rmdir() calls that create and remove classes. The remaining loops in fork() and exit() paths are proportional to the number of resource controllers -- currently limitedto 8 by CKRM_MAX_RES_CTLRS.
Classes also have an advantage when it comes to administrating resource management -- they are created and destroyed by an administrator and hence are easier to control. In contrast, the resource management decisions associated purely with tasks would disappear with the task. In many cases a task would be too short-lived for an administrator to manually intervene even if swarms of these tasks are created. Having this orthogonal hierarchy gives us the opportunity to manage all of these situations via a common interface and factors out overhead from the per-task solution you seem to be advocating.
I'm willing to discuss your ideas without patches but I think patches (even if incomplete) would be clearer.
> > It also has the added advantage that the resource controller writer do > > not have to spend their time in coming up with an interface for their > > controller. On the other hand if they do, the user finally ends up with > > multiple interface (/proc, sysfs, configfs, /dev etc.,) to do their > > resource management. > > So, maybe what is needed is an abstract parent RC that implements this > interface and lets the child RCs implement the specifics, and allows CKRM to > connect to the parent RC to allow finer RM control when a specific model > requires it.
I'm not sure what advantage that would give compared to CKRM as it stands now -- it sounds much more complex. Could you give an example of what kind of interfaces you're suggesting?
Cheers, -Matt Helsley
- 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/
| |