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: [XenPPC] [RFC] 64mb Chunk Allocator

So... in K42, chris yeoh recently explored a chunk based allocator, and he now has a prototype working in linux.  I think this would make much more sense for Xen than for Linux/k42.  I think the notion would be, that all allocates, even inside hypervisor for its own memory, are on behalf of some domain.  Allocate some chunks to the domain, and then sub-allocate for individual uses.  When the domain gets freed, all the memory of the chunks naturally gets freed.   If memory gets moved from one client to anther, chunks can be partial, when freed, but thats okay.  

I guess my impression is that we wanted to do something simple for now.  However, would it make sense to consider something like this?   Ryan, would it be crazy to try to get something like this into Xen?

I am talking now about the page allocator, but you might also want a heap allocator on top of this.

Sent by: xen-ppc-devel-bounces@xxxxxxxxxxxxxxxxxxx

06/23/2006 11:22 AM

Michal Ostrowski <mostrows@xxxxxxxxxxxxxx>
Re: [XenPPC] [RFC] 64mb Chunk Allocator

On Thu, 2006-06-22 at 16:56 -0400, Michal Ostrowski wrote:
> How is this expected to be integrated into existing memory allocators in
> Xen?  Would the other allocators always allocate their own chunks to
> work with and divide them up into smaller pieces or would other
> allocators compete with the chunk allocator?

Yeah, I think this is the key question.

Once you've given a chunk to the heap allocator, I don't think you can
ever expect it to be defragmented and given back. I worry about the
classic fragmentation problem:
"Create domain." -> -ENOMEM
"How much memory is free?" -> lots and lots

> Whereas the allocation strategies chosen by Linux encourage
> fragmentation and make memory hot-unplug difficult, this could be an
> opportunity to introduce a generic large-granularity memory-management
> layer that makes it easier to deal with hot-plug and large pages.

That's an interesting point.

Hollis Blanchard
IBM Linux Technology Center

Xen-ppc-devel mailing list

Xen-ppc-devel mailing list