Worried.
The object of this infrastructure is to get a unified interface for
resource management, irrespective of the resource that is being managed.
As I mentioned in my earlier email, subsystem experts are the ones who
will finally decide what type resource controller they will accept. With
VM experts' direction and advice, i am positive that we will get an
excellent memory controller (as well as other controllers).
As you might have noticed, we have gone through major changes to come to
community's acceptance levels. We are now making use of all possible
features (kref, process event connector, configfs, module parameter,
kzalloc) in this infrastructure.
Having a CPU controller, two memory controllers, an I/O controller and a
numtasks controller proves that the infrastructure does handle major
resources nicely and is also capable of managing virtual resources.
Hope i reduced your worries (at least some :).
Not all :) Let me explain.
Until you provided something more complex then numtasks, this
infrastructure is pure theory. For example, in your infrastracture, when
you will add memory resource controller with data sharing, you will face
that changing CKRM class of the tasks is almost impossible in a suitable
way. Another possible situation: hierarchical classes with shared memory
are even more complicated thing.
In both cases you can end up with a poor/complicated/slow solution or
dropping some of your infrastructre features (changing class on the fly,
hierarchy) or which is worse IMHO with incosistency between controllers
and interfaces.
Thanks,
Kirill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
