lkml.org 
[lkml]   [2012]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH -mm v2 00/11] mm: scalable and unified arch_get_unmapped_area
>>>>> "Andrew" == Andrew Morton <akpm@linux-foundation.org> writes:

Andrew> On Fri, 22 Jun 2012 10:24:58 -0400
Andrew> "John Stoffel" <john@stoffel.org> wrote:

>> >>>>> "Rik" == Rik van Riel <riel@surriel.com> writes:
>>
Rik> A long time ago, we decided to limit the number of VMAs per
Rik> process to 64k. As it turns out, there actually are programs
Rik> using tens of thousands of VMAs.
>>
>>
Rik> Performance
>>
Rik> Testing performance with a benchmark that allocates tens
Rik> of thousands of VMAs, unmaps them and mmaps them some more
Rik> in a loop, shows promising results.
>>
>> How are the numbers for applications which only map a few VMAs? Is
>> there any impact there?
>>

Andrew> Johannes did a test for that: https://lkml.org/lkml/2012/6/22/219

I don't see that in his results. But maybe (probably) I don't
understand what types of applications this change is supposed to
help. I guess I worry that this will just keep slowing down other
apps.

His tests seemed to be for just one VMA remapped with thousands in
use. Or am I missing the fact that all VMAs are in the same pool?

Andrew> Some regression with such a workload is unavoidable, I expect.
Andrew> We have to work out whether the pros outweigh the cons. This
Andrew> involves handwaving.

Yup, it does. Proof by vigorous handwaving is a time honored
tradition.

And I do see that the numbers aren't that much poorer, I just keep
thinking that if we can speed up the corner case, can't we also speed
up the normal case with a better algorithm or data structure?

John


\
 
 \ /
  Last update: 2012-06-23 18:41    [W:0.055 / U:6.124 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site