Subject: Re: kernel map entry merging and PR 24039
To: YAMAMOTO Takashi <firstname.lastname@example.org>
From: Andrew Brown <email@example.com>
Date: 11/30/2004 09:33:22
On Tue, Nov 30, 2004 at 08:48:38PM +0900, YAMAMOTO Takashi wrote:
>> > > 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" >-----|
firstname.lastname@example.org * "ah! i see you have the internet
email@example.com (Andrew Brown) that goes *ping*!"
firstname.lastname@example.org * "information is power -- share the wealth."