Subject: Re: kernel map entry merging and PR 24039
To: Andrew Brown <atatat@atatdot.net>
From: Matt Thomas <matt@3am-software.com>
List: tech-kern
Date: 02/10/2004 08:01:45
On Feb 10, 2004, at 6:01 AM, Andrew Brown wrote:

> On Mon, Feb 09, 2004 at 10:27:18PM -0800, Matt Thomas wrote:
>> At 06:03 PM 2/9/2004, 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.
>
> how can asserting UVM_FLAG_NOMERGE prevent splitting unless the
> allocation is less than three pages in size?  can't i simply make a
> three page allocation with UVM_FLAG_NOMERGE set and then unmap the
> middle page?

True but the current uses of uvm_map and uvm_unmap in the kernel
don't do that.

They simply undo a previous uvm_map.
-- 
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.