[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] Move MEMZONE_XEN to the last
>From: Jan Beulich [mailto:jbeulich@xxxxxxxxxx] >Sent: 2007年3月21日 18:29 > >>>> "Tian, Kevin" <kevin.tian@xxxxxxxxx> 21.03.07 06:56 >>> >>Zone index for domain heap is derived from bits, while zone index for >>xen heap takes 0 to catch all. This looks a bit messed which prevents >>future extension. For example, if Xen can be located at higher memory: >> - The assumption that domheap starts from MEMZONE_XEN+1 >>doesn't hold true >> - The memory within the very bit but out of xenheap can't be >>claimed by domheap since that bit belongs to xenheap exclusively > >Zone 0 has no implications on bit width - the only thing it prevents is >allocating page zero through the domain heap allocator), which >clearly must never be allowed (as pfn/mfn zero is used as error >condition in various places). I also can't see why it would conflict >with moving Xen out of (relatively) low memory (a plan I also had for >a while, bt didn't get to so far). Since 0-1Mb (grabbed by dom_io) is not initialized into either xen heap or domain heap, zone 0 will be always null for domain heap even not given to Xen. :-) But yes, now I'm inclined to agree with you no confliction with moving Xen to other place, if anyway MEMZONE_XEN has no implication on bit width while zone 0 is free to use. Thanks, Kevin > >>So how about moving MEMZONE_XEN to the last >>(current NR_ZONES plus 1)? That can ensure domheap covering all >>possible bits exactly. > >Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |