On Mon, Nov 03, 2003 at 11:49:51AM -0800, Matt Thomas wrote:
> 
> On Monday, November 3, 2003, at 09:25 AM, David Laight wrote:
> 
> >>how about we extend the pool code to handle objects larger than a 
> >>page?
> >
> >It would also be advantageous to allocate more than one page when
> >the required item is a significatant proportion of a page.
> >There is a lot of waste for anything that is between 1/2 a page and
> >2/3 a page that would be removed if two physical pages were allocated
> >each time the pool needed memory.
> 
> The problem is that ports who use a PMAP_MAP_POOLPAGE need physically
> contiguous pages for any multiple-page pool allocation.  UVM needs to
> be able to support that better.  (UVM should be able to "steal" an
> inuse unwire page that has the proper requirements to satisfy an
> allocation request and remap any uses of that page to a newly allocated
> free page).

we don't *have* to use TLB-bypass accesses for multi-page objects,
though it would be nice if we did eventually.  initially it would
be fine to map them in kernel_map (like we do for uareas now),
just to get the benefit of the standard interface and lazy freeing
and caching.  that's all that many platforms (such as x86) can do anyway.
the PMAP_MAP_POOLPAGE-style stuff can be added at any time later.

-Chuck