[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: doc on memory management

From: Vincent Guffens
Subject: Re: doc on memory management
Date: Tue, 02 Aug 2005 20:06:46 +0200
User-agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

Vincent Pelletier wrote:
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)
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
Version: GnuPG v1.4.1 (GNU/Linux)



___________________________________________________________________________ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur

Grub-devel mailing list

                                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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]