Re: [Xen-devel] Is QoS of virtual disk not necessary?

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 24/8/07 09:27, "Satoshi Uchida" <s-uchida@xxxxxxxxxxxxx> wrote:

>   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.

Another nice thing would be that if we do not use CFQ then we do not need a
kernel thread per VBD. We could support one kernel thread per blkback and
one kernel thread per VBD.

I don't know if both these models can be neatly supported by a single
consistent set of iomgr hooks.

>> 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?

Hmmm... Well actually all the blkdev stats are exported thru sysfs right
now, so already there are things that do not work well when blkback is in a
driver domain (e.g., xentop). Perhaps we should export everything thru
sysfs, but then provide a way to proxy that info through xenstore too, as an
optional extra (either a user-space daemon, or we could make it a kernel
driver option).

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel