Subject: Re: kernel map entry merging and PR 24039
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
From: Matt Thomas <matt@3am-software.com>
List: tech-kern
Date: 02/04/2004 17:45:03
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.