[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: doc on memory management
Re: doc on memory management
Tue, 02 Aug 2005 20:06:46 +0200
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Vincent Pelletier wrote:
-----BEGIN PGP SIGNED MESSAGE-----
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)
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
-----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
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