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


[Xen-devel] One question on alloc_bitmap

To: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] One question on alloc_bitmap
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Thu, 18 Sep 2008 23:16:02 +0800
Accept-language: en-US
Acceptlanguage: en-US
Delivery-date: Thu, 18 Sep 2008 08:17:51 -0700
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AckZoXZSoSkDATtZRuySnrsjCVd9SA==
Thread-topic: One question on alloc_bitmap
I have a question to the alloc_bitmap. Currently it is allocated in 
init_page_allocator() and is continous physical memory mapped in direct map 
(1:1 map) range. Would it be possible to support un-continous like what's done 
for frame table?
Several reason I can think out that can be improved is: a) if memory sparsed 
arranged, like large hole in the memory, it may cost some memory b) if we want 
to support memory hot add, we can't increase this bitmap. c) this map is not 
NUMA aware, I'm not sure if it has any performance impact, although it is not 
accessed frequently.

Any idea on it?

Yunhong Jiang

Xen-devel mailing list