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.