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]>
Sent by: [EMAIL PROTECTED] 08/09/2004 03:17 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
<<inline: graycol.gif>>
<<inline: pic27985.gif>>
<<inline: ecblank.gif>>
