WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 3/3] Replace slab.c with a very simple allocator.

To: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 3/3] Replace slab.c with a very simple allocator.
From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Date: Thu, 03 Feb 2005 11:51:58 +1100
Cc: Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 03 Feb 2005 00:53:55 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <E1CwNEL-0001W5-00@xxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <E1CwNEL-0001W5-00@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
On Wed, 2005-02-02 at 16:19 +0000, Ian Pratt wrote:
> > slab.c in Linux is not a very nice piece of code: the version in Xen has
> > been hacked a certain amount and is not a vision of beauty either.  
> > 
> > Given how rare and non-time-critical dynamic allocations are in Xen,
> > this replaces the 1800-line slab.c with a 160-line malloc.c which is
> > written as simply as possible for future enhancement.
> > 
> > Tested in userspace, boots Xen fine.
> 
> Rusty,
> 
> This turns out to be an oversimplification -- it doesn't boot for
> me as exec_domain's aren't 16 byte aligned and hence fxsave
> fails.

Damn, apologies for missing this requirement.  Good catch.

> I think we want to ensure that the object returned is always
> aligned to start on a L1 cache line boundary. I don't care that
> we burn some memory as we don't have lots of small allocs.

If I may suggest, I'd prefer to put this in the hands of the caller,
with an explicit alignment arg.  This simply falls out with this
type-safe versions using __alignof__, and should neatly document this
requirement, for example.

> Please could you adjust your patch having resync'ed from usntable.

Hmm, I hope that the bk snapshot is close enough.

Will do,
Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel

<Prev in Thread] Current Thread [Next in Thread>