At 05:14 PM 2/4/2004, YAMAMOTO Takashi wrote:
> > >pool_put is not only one which has the assumption.
> > >eg. uvm_km_kmemalloc1, in the case of UVM_KMF_NOWAIT.
> > >and i guess there're more...
> >
> > But uvm_km_kmemalloc1 shouldn't be splitting map entries.  It might need to
> > extend or allocate a new map entry.  But if it can't, then it should 
> fail the
> > allocation.  So I don't see an issue here.
>
>it calls uvm_unmap when uvm_pagealloc failed.

But if the old map entries that got released on the merge (because the VA
filled a gap between two existing map entries) were saved (new argument to
uvm_map), then they could easily be reclaimed by uvm_unmap (new uvm_unmap
with a third argument which is a linked list of uvm_map_entries to use, if
needed).  In this case uvm_unmap can never block since it will never need to
allocate a map entry.


-- 
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.