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: [EMAIL PROTECTED] • 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 <[EMAIL PROTECTED]> > >> > > > > 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. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. -- coreboot mailing list [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
