From owner-freebsd-current@FreeBSD.ORG Tue Nov 25 00:20:09 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 85EDD16A4CE; Tue, 25 Nov 2003 00:20:09 -0800 (PST) Received: from ms-smtp-03-eri0.socal.rr.com (ms-smtp-03-qfe0.socal.rr.com [66.75.162.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id F367743FD7; Tue, 25 Nov 2003 00:20:06 -0800 (PST) (envelope-from sean@mcneil.com) Received: from blue.mcneil.com (cpe-66-75-176-109.socal.rr.com [66.75.176.109])hAP8K4mB010815; Tue, 25 Nov 2003 00:20:04 -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 hAP8K33C076026; Tue, 25 Nov 2003 00:20:04 -0800 (PST) (envelope-from sean@mcneil.com) From: Sean McNeil To: Maxime Henrion In-Reply-To: <20031125081350.GE8404@elvis.mu.org> References: <1069747092.75674.6.camel@blue.mcneil.com> <20031125081350.GE8404@elvis.mu.org> Content-Type: text/plain Organization: Sean McNeil Consulting Message-Id: <1069748403.76000.1.camel@blue.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 25 Nov 2003 00:20:03 -0800 Content-Transfer-Encoding: 7bit X-DCC-dmv.com-Metrics: blue.mcneil.com 1181; Body=2 Fuz1=2 Fuz2=2 X-Virus-Scanned: Symantec AntiVirus Scan Engine 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:20:09 -0000 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. Thanks again, Sean On Tue, 2003-11-25 at 00:13, Maxime Henrion wrote: > Sean McNeil wrote: > > Hi everyone, > > > > I was wondering if there is a way to flush out pages in memory that > > might not be required. I have a device driver that allocates 16 distict > > buffers each 32K in size. This is done with a bus_dma call as they will > > be accessed by a PCI device. The problem is that if I do a compile on > > my system prior to trying to kldload the module, there isn't enough > > physical memory for the driver. I am assuming it is the disk cache that > > is eating up that memory and I want to flush out enough pages for my > > bus_dma allocation to work. > > > > Is this possible? Any and all comments are appreciated. > > The problem has probably nothing to do with the disk cache eating up > memory but I believe what you're seeing is physical address space > fragmentation. On x86, when devices want to perform DMA operations, > they are given physical addresses, not virtual ones as with other > architectures like sparc64 which have an IOMMU. This means that for > each of your 32k buffers, you need 8 _physically contiguous_ pages of > memory. > > Unfortunately, the more a system is running, the more the physical > address space tends to be fragmented, and it becomes impossible to > reserve large chunks of physically contiguous memory, hence why the > kldload is failing. > > If I remember correctly, Alan Cox intended to write a binary buddy > allocator to handle the physical address space (or do coalescing another > way, I'm not sure...) so that this particular problem is solved. > > Cheers, > Maxime