On Tue, Nov 30, 2004 at 08:48:38PM +0900, YAMAMOTO Takashi wrote:
>hi,
>
>> > > Module Name:  src
>> > > Committed By: matt
>> > > Date:         Tue Feb 10 01:30:49 UTC 2004
>> > >
>> > > Modified Files:
>> > >       src/sys/uvm: uvm.h uvm_km.c uvm_map.c uvm_map.h uvm_map_i.h
>> > >
>> > > Log Message:
>> > > Back out the changes in
>> > > http://mail-index.netbsd.org/source-changes/2004/01/29/0027.html
>> > > since they don't really fix the problem.
>> >
>> >what do you think a "real" fix is?
>> >are you going to fix all callers of uvm_unmap to be safe to sleep?
>> >
>> >(i'm not objecting to the backout)
>> 
>> I don't know quite yet.  Passing in UVM_FLAG_NOMERGE on the map will
>> will guarantee that uvm_unmap will not block since the uvm_map_entry
>> will never be split.  But it doesn't seem to be a good solution.
>
>is there any progress to fix this problem since then?
>
>i still think disabling entry merging (or, not to free memory for
>merged entries, at least) is a "real" fix because it's a design flaw
>to require memory allocation to free memory.

you can call it a design flaw if you want to, but imho it's more of a
flaw to consume more memory up front simply so that you don't have to
allocate it later.

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