the problem with using the pagedaemon is that it doesn't care what kind of
memory it frees.  so if the amount of AGP-addressable memory is small
compared to the total amount of memory, the pagedaemon will free up mostly
pages that you can't use.  if you leave those pages on the free list,
the pagedaemon will see that there are plenty of free pages and just go
back to sleep.  if you don't leave them on the free list but allocate them
temporarily so that the pagedaemon won't see them, then you could deadlock
if there just aren't enough freeable pages that are in your range.

I guess you could allocate the unusable pages temporarily and then avoid the
deadlock by checking if swap is nearly full each time you see that there
are no free pages.  that could result in nasty behaviour if you ultimately
fail to allocate the pages you want but have to fill up swap in order to
figure that out, but that's the best thing I see so far that doesn't involve
allocation early in the boot process.

-Chuck


On Tue, Sep 18, 2001 at 04:10:40PM +0200, Frank van der Linden wrote:
> 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
> 
> --