Date: Mon, 12 Jan 1998 13:29:01 -0700 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Terry Lambert <tlambert@primenet.com> Cc: gibbs@plutotech.com (Justin T. Gibbs), cjs@portal.ca, dg@root.com, alpha@FreeBSD.ORG Subject: Re: Alpha port.. Message-ID: <199801122031.NAA07053@pluto.plutotech.com> In-Reply-To: Your message of "Mon, 12 Jan 1998 18:49:47 GMT." <199801121849.LAA25925@usr04.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>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. Yes, that is the intent, as it is in the bus dma implementation I wrote, but by using a callback mechanism, the system only needs to pre-allocate enough space to handle a single transaction. Allocating additional space will improve performance, but can be performed lazily without preventing the system from running. The amount to pre-allocate should be tunable, but should not be the brute force of (#possible transactions * #possible bounce pages per transaction). The current implementation ensures that there is enough bounce space for at least one full transaction per client when the device requests a dma handle. I could easily add a static initial allocation, but at boot time, I question whether this will gain much since I allocate a page at a time and those pages do not need to be contiguous. For LKMs, the static allocation only postpones the inevitable since that pool could be exhausted at the time of the attach and attempts to add to it could fail without some form of page swapping performed by the kernel. >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). And this would still be possible since even transactions requested from an interrupt context can be deferred if the resources are not immediately available. How those resources are attained is an implementation detail. I'm mostly concerned with making the interface flexible enough in both NetBSD and FreeBSD so that bus dma implementations don't have to needlessly waste space. > Regards, > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. -- Justin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801122031.NAA07053>