Subject: Re: 1.6.2 kernel: ex driver sometimes can't allocate
To: None <tech-kern@NetBSD.org>
From: Chapman Flack <flack@cerias.purdue.edu>
List: tech-kern
Date: 09/21/2004 16:18:00
> A compromise might be the following: when certain memory pages are
> required but dirty, some *other* pages that are clean can be discarded,
> and the dirty pages shuffled around so that they now occupy their
> physical memory.

I like it - it's certainly a lot faster than kicking them to disk; now
is it fast enough to do within bus_dma_alloc( ...NOWAIT) ?  what are the
latency requirements there?

-Chap

hmm, another thought:  if you have a pre-reservation for some space, you can
decide in advance where that space is going to be.  when the time comes that
you need it, you might have to kick some pages out, but at least you've
already chosen the region you're going to kick them out of.  the compromise
above is in one way simpler (no reservation, can find the contig space
anywhere by shuffling some pages) and in one way more interesting: now how
do you decide in what region to do this?  I suppose it would be a search for
a region that (a) is dma-accessible for the bus in question, (b) scores well
relative to other choices on cost of dropping n clean pages plus cost of
shuffling m dirty ones, and as you could compare overlapping candidate regions
the algorithm could get interesting, and balancing the search cost with any
improvement in page shuffling cost.  I guess more sophisticated search can be
future work too; it suffices to have a dummy search that chooses an arbitrary
region regardless of cost and you just evict whatever you find there.

so reservation could reduce some allocation-time latency (from searching or
eviction cost, or both), but adds the complication of having to make
reservations, so depending on what latency is tolerable maybe it's overkill.