From owner-freebsd-current@FreeBSD.ORG Tue Nov 25 00:53:47 2003 Return-Path: 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 3BD7216A4CF; Tue, 25 Nov 2003 00:53:47 -0800 (PST) Received: from ms-smtp-02-eri0.socal.rr.com (ms-smtp-02-qfe0.socal.rr.com [66.75.162.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id A65B443FE0; Tue, 25 Nov 2003 00:53:45 -0800 (PST) (envelope-from sean@mcneil.com) Received: from blue.mcneil.com (cpe-66-75-176-109.socal.rr.com [66.75.176.109])hAP8rjiF009566; Tue, 25 Nov 2003 00:53:45 -0800 (PST) Received: from [66.75.176.109] (mcneil.com [66.75.176.109]) by blue.mcneil.com (8.12.10/8.12.10) with ESMTP id hAP8rd3C076416; Tue, 25 Nov 2003 00:53:39 -0800 (PST) (envelope-from sean@mcneil.com) From: Sean McNeil To: Maxime Henrion In-Reply-To: <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> <20031125083144.GF8404@elvis.mu.org> Content-Type: text/plain Organization: Sean McNeil Consulting Message-Id: <1069750418.76394.7.camel@blue.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 25 Nov 2003 00:53:39 -0800 Content-Transfer-Encoding: 7bit X-DCC-dmv.com-Metrics: blue.mcneil.com 1181; Body=2 Fuz1=2 Fuz2=2 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2003 08:53:47 -0000 Oh, I absolutely agree. I do not want any hacks. I was hoping that there might be an existing mechanism that was in place that would allow for the purging of unused physical pages by resource hogs. I am reminded of an old OS I was fond of: AmigaOS. It had a real nice feature where applications, drivers, etc. would register a "low memory" callback. Whenever the OS reached certain water-marks, these callbacks would get invoked. It was a nice clean way for shared libraries and drivers to cache things in memory, but then throw them away when things got tight. It is not a big deal for me. This is for a customer of mine and they are OK with loading the module early during boot when memory isn't fragmented yet. Just thinking "out text", Sean On Tue, 2003-11-25 at 00:31, Maxime Henrion wrote: > 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