[coreboot] libpayload memalign
jordan.crouse at amd.com
Tue Aug 19 21:20:14 CEST 2008
On 19/08/08 20:24 +0200, Stefan Reinauer wrote:
> Jordan Crouse wrote:
> > On 19/08/08 19:26 +0200, Stefan Reinauer wrote:
> >> --
> >> coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
> >> Tel.: +49 761 7668825 • Fax: +49 761 7664613
> >> Email: info at coresystems.de • http://www.coresystems.de/
> >> Registergericht: Amtsgericht Freiburg • HRB 7656
> >> Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
> >> Add memalign, get aligned memory.
> >> Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
> > This is a terrible amount of complexity for a simple aligned memory
> > function. I realize you are trying to fit within the 16k boundaries,
> > but come on - addr = ((addr + align - 1) / align) * align) is really all
> > you need. Yes, I know that ends up wasting memory.
> I remember from Patrick's explanation was that the memory should be
> freeable with the normal free().
> So a bit of complexity is also in that.
> Patrick can explain this better.
> Sure, it can be done simpler and less efficient. But from previous
> discussions I got the impression that this is not necessarily what we want.
> > So more importantly then this individual patch, it seems pretty clear
> > that we are getting ready to push the boundaries of the static 16k heap.
> > The time has come to replace it a dynamic engine. The dynamic engine can
> > take more advantage of the system memory, and we won't care so much if we
> > end up losing 13 bytes with a 16 byte alignment.
> > The questions now are - where should we put the heap? What sort of
> > implementation should we go for? Is the current mode scalable (probably
> > not)? I probably favor a linked list implementation. What restrictions
> > should we have on the size of the heap or the number of allocations?
> With regard to the fact that quite some payloads might want to load an
> OS at an arbitrary address, limiting the available memory to something
> considerably less than the maximum amount of memory makes sense. Does it?
> If we agree on that, the "dynamic" part would merely be to determine a
> good _heap and _eheap address during runtime.
> I'm not convinced yet, that the current scheme needs to be changed at
> all. It's working quite nicely for us. But then again, if you're going
> to make things more dynamic, I am all for it.
If it was working nicely for us, then memalign() would have been at most
an extra line or two.
Systems Software Development Engineer
Advanced Micro Devices, Inc.
More information about the coreboot