Return-Path: <linux-kernel-owner+akpm=40zip.com.au@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S316258AbSFDEkJ>; Tue, 4 Jun 2002 00:40:09 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S316300AbSFDEkI>; Tue, 4 Jun 2002 00:40:08 -0400
Received: from holomorphy.com ([66.224.33.161]:35203 "EHLO holomorphy")
	by vger.kernel.org with ESMTP id <S316258AbSFDEkH>;
	Tue, 4 Jun 2002 00:40:07 -0400
Date: Mon, 3 Jun 2002 21:40:02 -0700
From: William Lee Irwin III <wli@holomorphy.com>
To: Thunder from the hill <thunder@ngforever.de>
Cc: Lightweight patch manager <patch@luckynet.dynu.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Daniel Phillips <phillips@bonn-fries.net>,
        Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>
Subject: Re: linux-2.5.20-ct1
Message-ID: <20020604044002.GC8263@holomorphy.com>
Mail-Followup-To: William Lee Irwin III <wli@holomorphy.com>,
	Thunder from the hill <thunder@ngforever.de>,
	Lightweight patch manager <patch@luckynet.dynu.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Daniel Phillips <phillips@bonn-fries.net>,
	Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>
In-Reply-To: <20020604042300.GA8263@holomorphy.com> <Pine.LNX.4.44.0206032228550.3833-100000@hawkeye.luckynet.adm>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.25i
Organization: The Domain of Holomorphy
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

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 
> <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/