From owner-freebsd-current@FreeBSD.ORG  Tue Nov 25 00:31:45 2003
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 3573716A4CE
	for <freebsd-current@freebsd.org>;
	Tue, 25 Nov 2003 00:31:45 -0800 (PST)
Received: from elvis.mu.org (elvis.mu.org [192.203.228.196])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 8B3BD43F85
	for <freebsd-current@freebsd.org>;
	Tue, 25 Nov 2003 00:31:44 -0800 (PST)	(envelope-from mux@freebsd.org)
Received: by elvis.mu.org (Postfix, from userid 1920)
	id 7DC5A2ED44F; Tue, 25 Nov 2003 00:31:44 -0800 (PST)
Date: Tue, 25 Nov 2003 09:31:44 +0100
From: Maxime Henrion <mux@freebsd.org>
To: Sean McNeil <sean@mcneil.com>
Message-ID: <20031125083144.GF8404@elvis.mu.org>
References: <1069747092.75674.6.camel@blue.mcneil.com>
	<20031125081350.GE8404@elvis.mu.org>
	<1069748403.76000.1.camel@blue.mcneil.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1069748403.76000.1.camel@blue.mcneil.com>
User-Agent: Mutt/1.4.1i
cc: freebsd-current@freebsd.org
Subject: Re: memory allocation issue loading a kernel module
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2003 08:31:45 -0000

Sean McNeil wrote:
> Yes, thanks for the clarification.  I still am inclined to believe,
> though, that the disk driver is what is fragmenting the physical memory
> with disk cacheing.  It is only a theory, but it sounded plausible.

Maybe, but the root cause is not the disk caching.  It may be that this
subsystem is doing a lot of allocations/deallocations and thus leads to
physical address space fragmentation, but the root cause is how we deal
with physical address space, and the correct fix is not to add hacks into
the disk caching code.  I'm insisting on this because I don't want to see
people adding hacks here and there to workaround the problem.  Even if
you get the disk caching code to cause less fragmentation, fragmentation
_will_ happen.  At best it'll take a bit longer.

Cheers,
Maxime