This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Satoshi Uchida <s-uchida@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Is QoS of virtual disk not necessary?
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
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <012001c7e628$96933aa0$4c87380a@xxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acfkn1AvjVodwXJpTAeEc3jziy7dgwAGjNU+AFsdwQAAD6WpdQ==
Thread-topic: [Xen-devel] Is QoS of virtual disk not necessary?
User-agent: Microsoft-Entourage/
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