In article <1101815318.791041.10774.nullmailer@yamt.dyndns.org>,
YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp> 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.

I agree that requiring a memory allocation in order to free memory is
causing a problem. But at the same time, merging is highly desirable,
because otherwise you end up with a very fragmented memory map which
has both performance and memory use efficiency issues.

Maybe there is a way to make sure that you have enough memory to allocate
(and possibly reserve it) before you commit to do the merging, otherwise
you do the free with no merge. This way, you'll get most the benefit of
the merging without the undesirable deadlock.

christos