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

[Xen-devel] Idea: Small Address Spaces

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Idea: Small Address Spaces
From: Jacob Gorm Hansen <jacobg@xxxxxxx>
Date: Mon, 04 Apr 2005 16:55:08 -0700
Delivery-date: Mon, 04 Apr 2005 23:55:06 +0000
Envelope-to: www-data@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
User-agent: Mozilla Thunderbird 1.0 (X11/20050302)
hi,

in the cases where users (like me) wish to run Xen with MPI on Ethernets or similar, and don't care too much about driver isolation, I am thinking of trying to apply Jochen Liedtke's old 'small address spaces' hack, to see if I can improve domU I/O performance.

My idea is to reserve some additional virtual address space below Xen, e.g. at 0xF0000000, and map the kernel part of dom0* there permanently. The user space part of dom0 I would map as normal from 0 - 0xC0000000, to avoid relinking dom0 applications. I would use the segments to keep the domUs below 0xF0000000. In this way, TLB flushes should only be necessary when dom0 exits to user space, not when handling interrupts or when domUs are asking for I/O.

Ideally, I would move dom0 to ring0 to save the cost of switching from Xen to dom0, but I have no idea how much trouble this will cause.

I have been working a bit on this, and so far I have only managed to move dom0 to its new location, and to map the 0xF0000000 - 0xFC000000 range into the top of domU pgds instead of changing the cr3 (page table base) register. I have managed to break a lot of things, I see that as a good sign ;-)

I know this loses driver isolation, but I would argue that if it can be done relatively cleanly, and if it yields any performance improvements, a significant percentage of users would be willing to make that tradeoff. Naturally, this would be a (compile or run-time) option, not the default behavior.

Comments are welcome, now is the time to yell stop ;-)

Jacob


* This could probably be made to work with multiple IDDs as well, treating the 0xF0000000 slot as a cache of the last run driver-domain rather than as a permanent mapping.

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

<Prev in Thread] Current Thread [Next in Thread>