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

Or add an UVM_KMF_NOMERGE flag and pass that to uvm_map.  This
will prevent a merge on the VA region just mapped.  Then after
successfully getting the pages (at a point failure is no longer
possible), do a uvm_map_compress(map, kva, size) which clears the
UVM_KMF_NOMERGE flag and then tries to do the map entry merging
at that point.  If it can't, no problem.

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

Because it's just wasteful and slow things down.  18K+ map entries
*must* have a performance hit.

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