Date: Fri, 28 Feb 1997 16:45:20 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: tinguely@plains.nodak.edu (Mark Tinguely) Cc: terry@lambert.org, dg@root.com, hackers@freebsd.org, jpt@msc.edu Subject: Re: Assumptions about kmem_malloc()... Message-ID: <199702282345.QAA02574@phaeton.artisoft.com> In-Reply-To: <199702282308.RAA25795@plains.nodak.edu> from "Mark Tinguely" at Feb 28, 97 05:08:18 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > The kernel is an virtual-to-physical address space map, isn't it? You > > wouldn't need to introduce "handles" to do it, I think. > > I agree most kernel operations do not need wired contiguous physical memory, > a virtual contiguous would suit most operations. I was thinking of the device > drivers that require a physical contiguous address (or in the case of the > IDT ATM card it requires several physical addresses of contiguous buffer > addresses) programmed into it for long-term DMA. It seems to me, that with > our new devices using host memory to save board costs, we need larger and > larger chunks of contiguous physical memory because the DMA can't page fault > a missing virtual page. > > > > > It's not the kernel eating all the physical memory anyway. > > agreed, but as we allocate/release smaller chunks of physical unwired memory > for DMA operations, can we keep the holes large enough for future allocations? The reason I mentioned the virtual mapping is that it's possible to move everything virtual around in physical pages in order to create contiguous memory regions. Because of the reverse lookup problem, this would be generally useful only if the allocated regions were held for a relatively long time, once allocated. In effect, the reverse lookup and the space mapping act as a handle already. It's shuffling the mappings, and doing the physical page copies before the shuffle is put into effect that is the hard part. When an I/O request from a user process is DMA'ed in on an ISA machine with more than 16M of memory, it must always be bounced because the user address space may have been swapped, and if it were paged in for the write to the process space, then the page may find it has moved to high memory. Maybe it's time to look at preferential page location as an attribute of the request to page in? 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?199702282345.QAA02574>