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