Subject: Re: uvm_pglist alloc and WAITOK
To: Chuck Silvers <chuq@chuq.com>
From: Frank van der Linden <fvdl@wasabisystems.com>
List: tech-kern
Date: 09/18/2001 16:10:40
On Tue, Sep 18, 2001 at 06:51:24AM -0700, Chuck Silvers wrote:
> if a driver needs to allocate contiguous physical memory, it would be best
> to arrange to do that early in the boot process, before other processes
> have a chance to fragment memory. running a utility which allocates the
> memory as the first rc.d script would probably be good enough.
For the AGP code, you're not even talking about contiguous memory.
Just memory that is in 'bus-addressable' range. This can be a collection
of pages that are all over the place, as long as they are in range.
The GATT (see it as the AGP pagetable) will take care of the rest.
Furthermore, we're talking about memory that is needed because a
program requests it (and will free later). That program is the X
server. Currently, you can't start or restart an X server with
AGP support (on a machine with the i810 chipset, which is currently
the only driver on which it'll be used) after some filesystem activity,
because UBC is taking up all memory. Also, if you'd want to re-load a
driver LKM, this would fail as well (we hardly do this at the moment,
but might in the future). In both cases, allocating it at boottime is
not an option, because for the agp code that might be a very large
chunk of memory, and you might not even know that a driver LKM
will be (re-)loaded.
That's just not an acceptable situation. Surely it's not hard to
kick the pagedaemon and tell it to free up some pages.. "Solving"
this in userland seems, well.. horribly convoluted (and not really
possible in these cases). I suppose that the kernel code could
just do a plain malloc() first of the needed amount, free() it
and then immediately call bus_dmamem_alloc, but that just seems
silly.
- Frank
--
Frank van der Linden fvdl@wasabisystems.com
======================================================================
Quality NetBSD CDs, Support & Service. http://www.wasabisystems.com/