Re: [XenPPC] [RFC] 64mb Chunk Allocator

[Orran Y Krieger <okrieg@xxxxxxxxxx>]

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.

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

06/23/2006 11:22 AM

To	Michal Ostrowski <mostrows@xxxxxxxxxxxxxx>
cc	xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
Subject	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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel

_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel