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

even if you didn't merge your entry,
other cpus might merge your entry with their one. 
(yes, it's currently protected by biglock.
but i don't like to introduce new biglock dependencies.)

maybe you can
	1. uvm_map_prepare
	2. allocate pages
	3. uvm_map_enter
so that you don't need to do uvm_unmap.


honestly, i'm not sure why people hate to disable merging so much.
merging don't solve kva or memory fragmentation.
it only solve map entry fragmentation, which can be solved by
vmem-like chunking.  am i missing some points?

YAMAMOTO Takashi