From owner-freebsd-hackers  Fri Feb 28 15:08:34 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id PAA24136
          for hackers-outgoing; Fri, 28 Feb 1997 15:08:34 -0800 (PST)
Received: from plains.nodak.edu (tinguely@plains.NoDak.edu [134.129.111.64])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA24130
          for <hackers@freebsd.org>; Fri, 28 Feb 1997 15:08:29 -0800 (PST)
Received: (from tinguely@localhost) by plains.nodak.edu (8.8.4/8.8.3) id RAA25795; Fri, 28 Feb 1997 17:08:18 -0600 (CST)
Date: Fri, 28 Feb 1997 17:08:18 -0600 (CST)
From: Mark Tinguely <tinguely@plains.nodak.edu>
Message-Id: <199702282308.RAA25795@plains.nodak.edu>
To: terry@lambert.org
Subject: Re: Assumptions about kmem_malloc()...
Cc: dg@root.com, hackers@freebsd.org, jpt@msc.edu
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?

--mark.