WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "'Keir Fraser'" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] Is QoS of virtual disk not necessary?
From: "Satoshi Uchida" <s-uchida@xxxxxxxxxxxxx>
Date: Fri, 24 Aug 2007 17:27:20 +0900
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 24 Aug 2007 01:28:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2F1ED1F.14740%Keir.Fraser@xxxxxxxxxxxx>
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>
References: <01f101c7e49f$506185d0$4c87380a@xxxxxxxxxxxxxxxxxxx> <C2F1ED1F.14740%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acfkn1AvjVodwXJpTAeEc3jziy7dgwAGjNU+AFsdwQA=
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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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