[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] A tale of three memory allocators


  • To: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Sat, 19 Mar 2005 06:05:28 +0800
  • Delivery-date: Fri, 18 Mar 2005 22:07:41 +0000
  • List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
  • Thread-index: AcUrRksLbteuaumMSF6n8mcDfe9azQAp7M7gAAIKV5AABA3j8A==
  • Thread-topic: [Xen-devel] A tale of three memory allocators

>-----Original Message-----
>From: Magenheimer, Dan (HP Labs Fort Collins)
[mailto:dan.magenheimer@xxxxxx]
>Sent: Friday, March 18, 2005 12:12 PM
>
>I'm less concerned about NUMA configurations... I agree that
>NUMA support could be added later.  My first concern would
>be discontiguous memory as, on ia64, it is not uncommon
>for a machine to have a physical memory map of something like:
>
>0GB-1GB
>2GB-4GB
>64GB-69GB
>Total  8GB
>
>How does the Rusty Russell allocator handle a map like this?
>
>Dan

Rusty's allocator only handles slab, which is in upper layer upon buddy
system. Here what the holes actually affects is the memmap, which is the
base of buddy system. It's easier to add virtual memmap when initialize
frame_table, without any touch upon slab part.

Thanks,
Kevin


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.