At 04:15 PM 2/4/2004, YAMAMOTO Takashi wrote:
>hi,
>
> > Instead of disabling entry merging for kernel maps, how about the
> > following:
> >
> >       * For every kernel map entry that would be merged and freed,
> >         merge it, but instead of freeing the map entry, hang it off
> >         a free list for that map.
> >
> >       * If, when unmapping, you need to allocate a new map entry because
> >         of a split, pull an entry off that free list.
> >
> >       * Don't use those map entries on the free list for anything other
> >         than the unmap-split case.
> >
> > I guess the only issue then is to determine when free list entries can
> > be freed back when a split is not required on unmap.
> >
> > Anyway, I think this, or some variation of this, could solve the
> > problem and still let us have map entry merging for kernel maps.
>
>i've thought about this before the change and suggested on tech-kern.
>(and even implemented locally)
>
>however, i concluded that it didn't work.
>a split can occur even if you didn't merge entries
>(eg. when you map [0..100] and then unmap [10..90].
>of course, one doing such a thing can't assume unmap won't block.)
>and it can consume "reserved" entries for merged maps which are
>expected to be unmapped without blocking.

Maybe it's me, but I don't expect pool_put() to block.

I don't think this shouldn't be solved in uvm.  The solution should be in the
pool allocator itself.  Freeing pages should be deferred until either doing
a pool_get(PR_WAITOK) or wake up a kthread to do the reclaimation of the
pages.  Only then can the pool allocator return pages to uvm and then uvm
can proceed  normally to merge/split/whatever the map entries.

-- 
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this message.