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] Re: Fine-grained proxy resource charging

To: Rob Gardner <rob.gardner@xxxxxx>
Subject: Re: [Xen-devel] Re: Fine-grained proxy resource charging
From: Andi Kleen <ak@xxxxxxx>
Date: Mon, 22 Aug 2005 17:15:05 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, John L Griffin <jlg@xxxxxxxxxx>, Andi Kleen <ak@xxxxxxx>
Delivery-date: Mon, 22 Aug 2005 15:13:12 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4309EA83.1050001@xxxxxx>
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: <OFB1C72E4C.7209066C-ON85257065.001B4660-85257065.001DC6F9@xxxxxxxxxx> <p73br3qm7o4.fsf@xxxxxxxxxxxxx> <4309EA83.1050001@xxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> It's not a bad idea just because it's a hard problem.

Hard, likely slow (x86 has no really cheap
way to do microstate accounting), likely a lot of work,
and you have to fix up every driver in existence for it.
Not even talking about the VM which would need a kind
of redesign for it. For example pdflushd when flushing a dirty page has
no idea who dirtied it originally and there is simply no 
space in struct page to track such stuff.

> As demonstrated in the Usenix paper that John refers to 
> (http://www.usenix.org/publications/library/proceedings/usenix05/tech/general/cherkasova.html),
> the overhead in a driver domain can be very high under certain 
> circumstances. If you have "customers" sharing domains in a virtual 
> environment, you have to have some way of charging them fairly for resource 
> usage. I think the Xen I/O architecture needs to account for this somehow.

The only sane way would be different driver domains.


Xen-devel mailing list