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] One question on alloc_bitmap

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Wang, Shane" <shane.wang@xxxxxxxxx>
Subject: RE: [Xen-devel] One question on alloc_bitmap
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Fri, 19 Sep 2008 17:17:13 +0800
Accept-language: en-US
Acceptlanguage: en-US
Delivery-date: Fri, 19 Sep 2008 02:18:19 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C4F83064.272D8%keir.fraser@xxxxxxxxxxxxx>
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>
References: <E2263E4A5B2284449EEBD0AAB751098401ABC43C56@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C4F83064.272D8%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AckZoXZSoSkDATtZRuySnrsjCVd9SAAAKy0vACWOmZA=
Thread-topic: [Xen-devel] One question on alloc_bitmap
Keir Fraser <mailto:keir.fraser@xxxxxxxxxxxxx> wrote:
> On 18/9/08 16:16, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:
>> 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?
> Yes, it could be sparsely allocated in future. No reason why not.

Thanks for your clarification. We ask this because we are considering memory 

Yunhong Jiang

> -- Keir

Xen-devel mailing list