From: Vincent Pelletier <subdino2004@yahoo.fr>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: doc on memory management
Date: Tue, 02 Aug 2005 18:19:07 +0200 [thread overview]
Message-ID: <42EF9CFB.7040804@yahoo.fr> (raw)
In-Reply-To: <42EF862F.1080306@inma.ucl.ac.be>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 2058 bytes --]
-----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"
the reason why the first free chunk of the ring is sometime moved
the reason why alloc'ed chunks were removed from the list
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 :).
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.
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).
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
next prev parent reply other threads:[~2005-08-02 16:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-02 14:41 doc on memory management Vincent Guffens
2005-08-02 15:36 ` Vladimir Serbinenko
2005-08-02 18:10 ` Vincent Guffens
2005-08-02 16:19 ` Vincent Pelletier [this message]
2005-08-02 18:06 ` Vincent Guffens
2005-08-02 19:24 ` Vincent Pelletier
2005-08-02 20:41 ` Yoshinori K. Okuji
2005-08-03 20:14 ` Vincent Pelletier
2005-08-03 11:19 ` Marco Gerards
2005-08-08 15:41 ` Vincent Guffens
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42EF9CFB.7040804@yahoo.fr \
--to=subdino2004@yahoo.fr \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.