lkml.org 
[lkml]   [2015]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] mm: change find_vma() function
From
Date

> On Dec 15, 2015, at 05:11, Kirill A. Shutemov <kirill@shutemov.name> wrote:
>
> On Mon, Dec 14, 2015 at 06:55:09PM +0100, Oleg Nesterov wrote:
>> On 12/14, Kirill A. Shutemov wrote:
>>>
>>> On Mon, Dec 14, 2015 at 07:02:25PM +0800, yalin wang wrote:
>>>> change find_vma() to break ealier when found the adderss
>>>> is not in any vma, don't need loop to search all vma.
>>>>
>>>> Signed-off-by: yalin wang <yalin.wang2010@gmail.com>
>>>> ---
>>>> mm/mmap.c | 3 +++
>>>> 1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/mm/mmap.c b/mm/mmap.c
>>>> index b513f20..8294c9b 100644
>>>> --- a/mm/mmap.c
>>>> +++ b/mm/mmap.c
>>>> @@ -2064,6 +2064,9 @@ struct vm_area_struct *find_vma(struct mm_struct *mm, unsigned long addr)
>>>> vma = tmp;
>>>> if (tmp->vm_start <= addr)
>>>> break;
>>>> + if (!tmp->vm_prev || tmp->vm_prev->vm_end <= addr)
>>>> + break;
>>>> +
>>>
>>> This 'break' would return 'tmp' as found vma.
>>
>> But this would be right?
>
> Hm. Right. Sorry for my tone.
>
> I think the right condition is 'tmp->vm_prev->vm_end < addr', not '<=' as
> vm_end is the first byte after the vma. But it's equivalent in practice
> here.
>
this should be <= here,
because vma’s effect address space doesn’t include vm_end add,
so if an address vm_end <= add , this means this addr don’t belong to this vma,

> Anyway, I don't think it's possible to gain anything measurable from this
> optimization.
>
the advantage is that if addr don’t belong to any vma, we don’t need loop all vma,
we can break earlier if we found the most closest vma which vma->end_add > addr,
>>
>> Not that I think this optimization makes sense, I simply do not know,
>> but to me this change looks technically correct at first glance...
>>
>> But the changelog is wrong or I missed something. This change can stop
>> the main loop earlier; if "tmp" is the first vma,
>
> For the first vma, we don't get anything comparing to what we have now:
> check for !rb_node on the next iteration would have the same trade off and
> effect as the proposed check.
Yes
>
>> or if the previous one is below the address.
>
> Yes, but would it compensate additional check on each 'tmp->vm_end > addr'
> iteration to the point? That's not obvious.
>
>> Or perhaps I just misread that "not in any vma" note in the changelog.
>>
>> No?
>>
>> Oleg.
>>

i have test it, it works fine. :)
Thanks






\
 
 \ /
  Last update: 2015-12-15 08:01    [W:0.088 / U:0.548 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site