From owner-freebsd-hackers  Fri Feb 28 15:50:00 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id PAA26655
          for hackers-outgoing; Fri, 28 Feb 1997 15:50:00 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA26649
          for <hackers@freebsd.org>; Fri, 28 Feb 1997 15:49:54 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA02574; Fri, 28 Feb 1997 16:45:20 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199702282345.QAA02574@phaeton.artisoft.com>
Subject: Re: Assumptions about kmem_malloc()...
To: tinguely@plains.nodak.edu (Mark Tinguely)
Date: Fri, 28 Feb 1997 16:45:20 -0700 (MST)
Cc: terry@lambert.org, dg@root.com, hackers@freebsd.org, jpt@msc.edu
In-Reply-To: <199702282308.RAA25795@plains.nodak.edu> from "Mark Tinguely" at Feb 28, 97 05:08:18 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> >  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.