[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Satoshi Uchida <s-uchida@xxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Fri, 24 Aug 2007 16:36:41 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 24 Aug 2007 08:37:33 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acfkn1AvjVodwXJpTAeEc3jziy7dgwAGjNU+AFsdwQAAD6WpdQ==
  • Thread-topic: [Xen-devel] Is QoS of virtual disk not necessary?

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.