On Mon, 3 Jun 2002, William Lee Irwin III wrote:
>> There were discussions about a number of these patches resulting in
>> changes, would you mind letting me know what versions of these things
>> you're pushing upstream and let me hand you updates?
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
> 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.
===== 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 email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 07 2002 - 22:00:18 EST