Date: Mon, 12 Jan 1998 18:49:47 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: gibbs@plutotech.com (Justin T. Gibbs) Cc: cjs@portal.ca, dg@root.com, gibbs@plutotech.com, alpha@FreeBSD.ORG Subject: Re: Alpha port.. Message-ID: <199801121849.LAA25925@usr04.primenet.com> In-Reply-To: <199801100638.XAA25199@pluto.plutotech.com> from "Justin T. Gibbs" at Jan 9, 98 11:36:05 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 3) bus dma operations are completed through a software interrupt driven > callback mechanism which allows for you to lazily allocate resources > and even limit the amount of pages allocated for the bounce pool to > be less than the total that might possibly be needed at one time. > On my 32MB system running a tagged queuing capable ISA SCSI adapter > under heavy load, I never saw even 128K of bounce pages in use at a > given time. Allocating the 1MB that NetBSD does for ISA 1542 support > is a waste of memory. I think the intent of this allocation was to provide a split memory domain. All DMA'ing ISA devices, DMA'ing EISA devices on broken chipsets (like HiNT), and Amiga devices accessed through "chip RAM", as well as some systems I'm probably not immediately aware of, have two classes of memory. I think the allocation was to gather up all memory in a class, before it could be fragmented in normal use. I think this is probably still necessary, at least until it's possible to relocate physical memory allocations (something I'm a big fan of to allow for freeing up contiguous zones for lazy allocation of things like quick-cam and QIC-40/80 tape buffers). Right now, there is not the concept of kernel page relocation (a practice only one step removed from generalized kernel paging), and so it is not possible to do a contiguous allocation -- nor to allocate a "chip RAM" (read "low memory") bounce buffer -- after fragmentation has taken place. At worst, this allocation should remain a compile time option; at best, it should remain generally until some form of kernel physical backing page relocation for pages that don't care if they are physically in low memory. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801121849.LAA25925>