At 05:06 PM 2/4/2004, YAMAMOTO Takashi wrote:
>hi,
>
> > 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.
>
>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.

If things are blocking when they shouldn't be, it's a bug and should
be fixed, not kludged around.

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