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: "'Keir Fraser'" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] Is QoS of virtual disk not necessary?
From: "Satoshi Uchida" <s-uchida@xxxxxxxxxxxxx>
Date: Tue, 28 Aug 2007 18:07:35 +0900
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, 'Andi Kleen' <andi@xxxxxxxxxxxxxx>
Delivery-date: Tue, 28 Aug 2007 02:08:32 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2F4B999.148C5%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: <012001c7e628$96933aa0$4c87380a@xxxxxxxxxxxxxxxxxxx> <C2F4B999.148C5%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acfkn1AvjVodwXJpTAeEc3jziy7dgwAGjNU+AFsdwQAAD6WpdQCLjzEw

> On 24/8/07 09:27, "Satoshi Uchida" <s-uchida@xxxxxxxxxxxxx> wrote:
> > 
> > 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.

First, I fell that integrating into one kernel thread is a nice ways.
I/O requests can be controlled only by implementing any queuing techniques, and 
it is not need to control threads

However, usage of thread per VBD has advantage of simplifying to control event 
channels (ring buffer) and to manage information of VBDs (rd-reqs wr-reqs, 
...), etc.
So, I think that it is not needed to unite their threads.

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

It is nice to implement interface via xenstore.
The xenstore is implemented on any OS (Linux or Solaris) and it will be 
implemented on other OSs in future.
Maybe, there are sysfs in only Linux and there are not sysfs in other OS.
-- Perhaps there are similar systems such as devfs. --
Therefore, Using sysfs interface becomes OS-specific, but using xenstore is 

Satoshi UCHIDA

Xen-devel mailing list