Re: doc on memory management

[Vincent Guffens]

Vincent Pelletier wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Vincent Guffens wrote:
>
> > I have written some doc about mm in grub2.
>
>
> Nice work, explained with nice and clear schematics.
> Now I understand that piece of code :).
> I had trouble understanding :
>  the macro you explain in "Allocation memory"

Is it the calculation of the number of blocks n to allocate ?

>  the reason why the first free chunk of the ring is sometime moved

I found one reason in the Knuth's book I mentioned in the introduction 
but I'm not too sure it really applies. The argument is that if you 
always start looking at the same first header, you will tend to 
accumulate after a few  allocations/deallocations a long list of free 
small chunks after the first free chunk. So if you have to allocate a 
bigger block, you will have to traverse this list first.

>  the reason why alloc'ed chunks were removed from the list

It makes the allocation faster as the list you have to traverse is smaller.

> I wonder why the region header contains, to me, a useless field : addr.
> It is only set in grub_mm_init_region, invariably to the first header
> which is invariably at the same offset from the region beginning,
> defined by GRUB_MM_ALIGN. I don't think loosing sizeof(int) bytes is
> critical, though, as it would be padded anyway. It only made my
> comprehension of what's going on a little harder :).

yes, it is not used anywhere !


> I see a light improvement in grub_mm_init_region :
>   /* If this region is too small, ignore it.  */
>   if (size < GRUB_MM_ALIGN * 2)
>     return;
> If the region is 2*GRUB_MM_ALIGN, we can put a grub_mm_header_t plus a
> grub_mm_region_t, and it would be full. Maybe adding 1 byte (or more)
> might make more sense (but has it any practical impact...).
>
> My realloc implementation handled the case where the realloc'ed block
> had enough space after to expand. I might send a patch for this someday
> if anyone finds it interesting to add.

That would probably be a better way of doing it.

> I also implemented a memory defrag that merges successive free chunks in
> one bigger. Although it relied on the fact both alloc'ed and free chucks
> are known I think it can be adapted (if h->next != h+h->size*16, don't
> merge h and h->next) and even a bit faster (as we only see free chunks).

I don't think this is needed in this case as all the necessary merging 
is done when a  chunk is freed.

> Vincent Pelletier
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQFC75z7FEQoKRQyjtURAla2AJ9SZk9V8RSHhDHm0hajC5uOA+f28wCglptX
> mpVBwRDWdcPc+uAxuSvJcWA=
> =1Sd1
> -----END PGP SIGNATURE-----
>
>         
>
>         
>                 
> ___________________________________________________________________________ 
> Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
> Téléchargez cette version sur http://fr.messenger.yahoo.com
>
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel


--
                                Vincent Guffens
                                PhD Student UCL/CESAME
                                tel:   +32 10 47 80 30
Value your freedom, or you will lose it, teaches history.
"Don't bother us with politics," respond those who don't want to learn.
                -- Richard M. Stallman