Xen devel - Feb 2005 - RE: [PATCH 3/3] Replace slab.c with a very simpleallocator.

> > 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel