RE: [PATCH 3/3] Replace slab.c with a very simpleallocator.

RE: [PATCH 3/3] Replace slab.c with a very simpleallocator.

[Ian Pratt]

> > 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.

Hmm. I think pretty much everything we allocate is substantially biger
than a cache line, so there really isn't a whole lot of advantage in
doing this. We'd certainly have to go around sprinkling
__cacheline_aligned in a few more of our structure definitions to avoid
false sharing. BTW, I notice we use "__attribute__ ((aligned (X)))" in a
number of places as well as __alignof__. I presume they're the same
thing?

Out of interest, how do you extract information about such attributes
about structure definitions in a macro? 

> > Please could you adjust your patch having resync'ed from usntable.
> 
> Hmm, I hope that the bk snapshot is close enough.

The snapshot from last night should be OK (Keir removed _xmalloc late
last night GMT, so make sure you have this).

Thanks,
Ian


-------------------------------------------------------
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

Re: [PATCH 3/3] Replace slab.c with a very simpleallocator.

[ultraptr]

I wonder what are reasons for this replacement. From outside it looks like
proven and fast slab allocator is being replaced with slow and new one just
for sake of size and beauty of source codes?

--


-------------------------------------------------------
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

Re: [PATCH 3/3] Replace slab.c with a very simpleallocator.

[David Hopwood]

ultraptr@pacbell.net wrote:
> I wonder what are reasons for this replacement. From outside it looks like
> proven and fast slab allocator is being replaced with slow and new one just
> for sake of size and beauty of source codes?

Read the paper describing the original version of the slab allocator
(http://citeseer.ist.psu.edu/bonwick94slab.html), and then look at how it
is used in Xen (the calls that are being replaced by xmalloc in the patch).

 From this it is clear that the feature that results in most of the
allocator's complexity (retaining parts of the initialized state of
objects to reduce the cost of reinitialization) is not used at all by Xen.

-- 
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>



-------------------------------------------------------
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

Re: [PATCH 3/3] Replace slab.c with a very simpleallocator.

[Rusty Russell]

On Thu, 2005-02-03 at 11:44 -0800, ultraptr@pacbell.net wrote:
> I wonder what are reasons for this replacement. From outside it looks like
> proven and fast slab allocator is being replaced with slow and new one just
> for sake of size and beauty of source codes?

Yes, that's approximately correct.  Slow, of course, is arguable: it is
possible that the old code was slower, given the setup time and how
infrequently allocations are actually used.  The point here is that it
is quite possible that someone may want to make modifications to the
allocator which will be far simpler on the new code than the old.

In the finest book ever written on computer programming, Kernighan and
Plauger wrote "Don't patch bad code -- rewrite it".  I agree.

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

RE: [PATCH 3/3] Replace slab.c with a very simpleallocator.

[Ian Pratt]

> I wonder what are reasons for this replacement. From outside 
> it looks like
> proven and fast slab allocator is being replaced with slow 
> and new one just for sake of size and beauty of source codes?

The other way of looking at this is we'd be reaplacing an allocator that
almost no-one understands with one that's simple and we can easily be
evolved as required. It's also rather easier to "verify" its
correctness. 

Since the only dynamic allocation Xen does is on domain creation, we
really don't need anything too clever.

I can see your point of view, but asthetics often turn out to be
important when it comes to maintenance.

Ian



-------------------------------------------------------
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