Hi, Keir.
Thanks for comment.
> First impression was a lot of plumbing and not much in the way of
> moving parts.
What does this means?
Are "iomgr_xx" procedures too much for the turn-based control module?
E.g. the iomgr_oo_abort_request_fn procedure is not used in turn-based control
module.
> Also of course we have CFQ on Linux -- I suspect the kinds of changes
> you are suggesting would not be popular with kernel maintainers since
> they will argue there is already an I/O scheduling subsystem. :-)
I think that using I/O scheduling subsystem is one of solutions.
But, I fear two things.
One is that CFQ can be used only if a driver domain (or dom0) is only Linux.
In future, driver domains will be choose any types of OS, and they don't have
same I/O scheduling mechanism.
And there are also many I/O schedulers in Linux, and driver domains will be
choose some schedulers.
Therefore, I/O control is not dependent with I/O scheduler in specific type
of OS.
Another is that CFQ is developed for desktop system and for private
environments.
So, this may not be suitable in virtualization environments.
And, a setting parameter of CFQ is too simple, namely it have only 8-level
priority ranks.
Therefore, it is difficult to apply CFQ into huge virtualization system.
E.g. for many domains, it is difficult to set them by a percentage.
Therefore, I think that it is better to develop OS-agnostic I/O control.
> On the other hand, if you want to run a block driver in a driver
> domain (and so outside dom0) then having a programmatic scheduling
> interface via xenstore is quite nice...
Does this mean that interfaces should not be implemented by insmod or rewriting
sysfs entries, but should be implemented by xenstore and xm commands?
Thanks.
---------------------------------------------
Satoshi UCHIDA
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home