Narasimha...
You are correct that from a management perspective the current model seems cleaner. But remember the lumping together of memory and (cpu/io) into the same class is effectively broke right now. So that problem is going to be exposed already ...
With respect to CRBCE .. The classification engine works in two phases. The first one is passive classification (determine the class). After the core successfully assigned the class the CE is (*notified)(..) about the successful class change. Its only these notifications that are driven up to user level monitoring agents and not the classifications.
As for the new model if adopted, I envision that the (*notify) will similar to the classification obtain vector of successful resource class assignments, that will be pushed up as a reclassification event.
Yes, that is indeed a bit more cumbersome, but it does allow the user agent to treat it as a single event.
The new model that we are discussing does not change things tremendously
internally. The current classtypes are still needed, but are not externally visible anymore. We assume that a resource controller manipulates only one kernel object ( task, address space, socket, ..).
These kernel objects still need to represented by an internal structure
that will closely follow the current classtype. Difference is there will be no representation of these in either /rcfs nor in /rcfs/ce.
The CKRM_EVENTS_ .. likely will stay the same and as Shailabh has summed up our discussions during and since OLS on this, a kernel object type registeres which CKRM_EVENTS are of interest, resource controllers identify which kernel object they manipulate and thus it allows us to identify which resource controllers need to be involved in certain events.
-- Hubertus
Narasimha Sharoff wrote:
Another issue could be: Having a set of classes one per resource controller results in a set of classid's that need to be managed.
In case of CRBCE where we get events, classid's belonging to a task needs to be tied together so that the events can be associated correclty. ( example: a task exit event now could be a set of task exit event(s) that needs to be associated correctly)
-Narasimha
Shailabh Nagar <[EMAIL PROTECTED] .com> To Sent by: ckrm-tech [EMAIL PROTECTED] <[EMAIL PROTECTED]> ists.sourceforge. cc net Subject [ckrm-tech] CE changes for split 08/09/2004 03:17 ctlrs PM
Another ramification of splitting controllers up is the impact on the classification engine.
While discussing CE's, its useful to keep in mind that rule-based CE's are expected to be commonly used but one can have different ones. The role of the CE, in the current CKRM design, is to provide a non-binding recommendation for the class to which an object belongs. CE's do not initiate any actions, atleast for now.
The abstract definition of a CE's role does not help much when it comes to discussing changes to the /rcfs/<classtype> hierarchy. Taking RBCE's design is more useful.
RBCE is connected to the /rcfs/<classtype> namespace through the target specified in its rules.
A user wanting to continue using a single hierarchy could create per-controller hierarchies that are identical i.e. /rcfs/cpu/<common hier> /rcsf/io/<common hier> etc. But when it comes to defining rules, she would need to define multiple rules with the same left hand side (AND of attribute-value pairs) but different rhs (target).
e.g.
uid=10, target=/rcfs/taskclass/c1
becomes
uid=10, target=/rcfs/cpu/c1 uid=10, target=/rcfs/io/c1
There are two proposals for this aspect of CE-multiple hierarchy interactions:
1. CE remains at the current, single location (/rcfs/ce) but allows multiple targets to be specified.
+ simplifies manual entry of rules + assists rbce in optimizing evaluation by grouping rules with the same lhs.
2. The CE interface is split up into the per-controller directories i.e. multiple /rcfs/<ctlr>/ce directories.
+ more intuitive location for user. Restrictions on target types, attributes are easier to enforce. - entering rules for "synchronized" hierarchies is more cumbersome - evaluation optimizations gone unless RBCE can recognize similarities
The second major effect of multiple controllers on the CE arises out kernel events which could result in reclassification. Currently, each classtype indicates interest in an event. When the event occurs, all interested classtypes get called. The classtype code, in turn, calls the CE with the right object (task or socket) and gets back the new core class for the object. It changes the class of the object and informs controller of the change.
There are a couple of proposals for how this could change:
1. Each controller is allowed to independently register interest in a kernel event supported by CKRM (supported in the sense we have a hook in it).
+ All controllers don't get called on each event
- If the user defines a rule that does get triggered by an event that a controller has chosen to ignore, it could lead to unexpected behaviour. Its not clear on what basis a controller could decide, a priori, to restrict its interest, unless such a direction were to come (through /rcfs/<ctlr>/config, say) from the user who is also creating the rules.
2. We continue with the current design where the object type, not the controller, determines if controllers acting on the object should be called.
In either alternative above, to reduce the number of calls that the CKRM core would need to make into the CE at each event, one could group the controllers of interest into a list and request the CE for classification results for each list element. e.g if cpu, io are registered currently, on uid change one call is made into the CE asking for the new cpu, io classes to be assigned to the task and the resulting list is iterated over to make per-controller callbacks.
Comments ?
-- Shailabh
------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
