>> >however, i concluded that it didn't work.  
>> >a split can occur even if you didn't merge entries
>> >(eg. when you map [0..100] and then unmap [10..90].
>> >of course, one doing such a thing can't assume unmap won't block.)
>> >and it can consume "reserved" entries for merged maps which are
>> >expected to be unmapped without blocking.
>> 
>> if the problem was uvm_unmap() sleeping when unmapping something
>> because it needed to allocate a new vm_map_entry in order to perform a
>> split, your example above demonstrates that disabling merging cannot
>> solve the problem because merging could not have led to your
>> configuration above in the first place.
>
>sorry, i can't understand what you're saying.
>what's "your configuration above"?  unmapping middle of a map? 
>if so, i meant it's a bug of caller if it assumes it won't sleep.

"configuration above" means the situation where you have [0-100]
mapped and you unmap [10-90].  mapping [0-100] doesn't involve
merging.  i presume that we end up sleeping because we need to
allocate a new entry.  consider also that while unmapping the middle
of a region involves allocating a new map entry, simply changing the
permissions on the middle of a region involves allocating *two* new
map entries.

personally, i'm still waiting for someone to confirm the "sleeping
when unmapping" thing.  or did someone do that already?

>> >however, i agree that it isn't pretty to have ton of entries.
>> >given most of in-kernel entries are of the same size,
>> >i'm wondering about gathering them into large chunks.
>> >(maybe it'd be better to have a framework like solaris vmem?)
>> 
>> a better allocator won't have the same effect, it will just be
>> different.  the allocator is the same whether you merge or don't
>> merge.  the only difference is the overhead of allocating when you
>> need less map entries (there are less map entries to scan, and less
>> memory consumed by them).  in the end, the map entries will still mean
>> the same thing.
>
>i don't see any reason to use the same vm_map_entry structure for
>chunked blocks.

even if you used different structures for chunked blocks, you'd still
have the memory allocated underneath them.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."