On Mon, Jun 03, 2002 at 10:30:18PM -0600, Thunder from the hill wrote:
> Since you gave it no version number, it's exactly the version which is
> saved at
> <URL:ftp://luckynet.dynu.com/pub/linux/2.5.20-ct1/single-patches/>
> Usually the latest available.
Rusty Russell gave me copious assistance in clarifying and verifying the
effectiveness of the explanation given in updated buddy comment patches.
Please replace the version you've provided with the following.
Thanks,
Bill
===== mm/page_alloc.c 1.63 vs edited =====
--- 1.63/mm/page_alloc.c Tue May 28 16:57:49 2002
+++ edited/mm/page_alloc.c Mon Jun 3 15:21:55 2002
@@ -82,10 +82,13 @@
* at the bottom level available, and propagating the changes upward
* as necessary, plus some accounting needed to play nicely with other
* parts of the VM system.
- *
- * TODO: give references to descriptions of buddy system allocators,
- * describe precisely the silly trick buddy allocators use to avoid
- * storing an extra bit, utilizing entry point information.
+ * At each level, we keep one bit for each pair of blocks, which
+ * is set to 1 iff only one of the pair is allocated. So when we
+ * are allocating or freeing one, we can derive the state of the
+ * other. That is, if we allocate a small block, and both were
+ * free, the remainder of the region must be split into blocks.
+ * If a block is freed, and its buddy is also free, then this
+ * triggers coalescing into a block of larger size.
*
* -- wli
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/