From: "John Stoffel" <john@stoffel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: John Stoffel <john@stoffel.org>, Rik van Riel <riel@surriel.com>,
linux-mm@kvack.org, aarcange@redhat.com, peterz@infradead.org,
minchan@gmail.com, kosaki.motohiro@gmail.com,
andi@firstfloor.org, hannes@cmpxchg.org, mel@csn.ul.ie,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm v2 00/11] mm: scalable and unified arch_get_unmapped_area
Date: Sat, 23 Jun 2012 12:03:48 -0400 [thread overview]
Message-ID: <20453.59620.255516.321417@quad.stoffel.home> (raw)
In-Reply-To: <20120622144714.440f8529.akpm@linux-foundation.org>
>>>>> "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
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-06-23 16:04 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-21 21:57 Rik van Riel
2012-06-21 21:57 ` [PATCH -mm v2 01/11] mm: track free size between VMAs in VMA rbtree Rik van Riel
2012-06-22 9:57 ` Peter Zijlstra
2012-06-22 9:58 ` Peter Zijlstra
2012-06-22 14:11 ` Rik van Riel
2012-06-22 14:13 ` Peter Zijlstra
2012-06-22 14:25 ` Rik van Riel
2012-06-22 14:37 ` Peter Zijlstra
2012-06-22 15:41 ` Rik van Riel
2012-06-25 19:29 ` Peter Zijlstra
2012-06-25 21:52 ` Rik van Riel
2012-06-26 8:31 ` Peter Zijlstra
2012-06-26 13:05 ` Rik van Riel
2012-06-26 13:45 ` Peter Zijlstra
2012-06-26 15:49 ` Rik van Riel
2012-06-27 12:27 ` Peter Zijlstra
2012-06-26 8:37 ` Peter Zijlstra
2012-06-22 10:02 ` Peter Zijlstra
2012-06-29 23:46 ` Michel Lespinasse
2012-07-03 21:37 ` Rik van Riel
2012-07-03 23:16 ` Michel Lespinasse
2012-07-04 10:12 ` Peter Zijlstra
2012-06-21 21:57 ` [PATCH -mm v2 02/11] mm: rearrange vm_area_struct for fewer cache misses Rik van Riel
2012-06-21 21:57 ` [PATCH -mm v2 03/11] mm: vma_adjust: only call adjust_free_gap when needed Rik van Riel
2012-06-21 21:57 ` [PATCH -mm v2 04/11] rbtree: add helpers to find nearest uncle node Rik van Riel
2012-06-22 9:49 ` Peter Zijlstra
2012-06-21 21:57 ` [PATCH -mm v2 05/11] mm: get unmapped area from VMA tree Rik van Riel
2012-06-30 1:33 ` Michel Lespinasse
2012-07-03 0:23 ` Michel Lespinasse
2012-06-30 2:42 ` Michel Lespinasse
2012-06-21 21:57 ` [PATCH -mm v2 06/11] mm: arbitrary address ranges for arch_get_unmapped_area Rik van Riel
2012-06-21 21:57 ` [PATCH -mm v2 07/11] mm: make cache alignment code generic Rik van Riel
2012-06-30 2:22 ` Michel Lespinasse
2012-06-21 21:57 ` [PATCH -mm v2 08/11] mm: remove x86 arch_get_unmapped_area(_topdown) Rik van Riel
2012-06-21 21:57 ` [PATCH -mm v2 09/11] mm: remove MIPS arch_get_unmapped_area code Rik van Riel
2012-06-21 21:57 ` [PATCH -mm v2 10/11] mm: remove ARM arch_get_unmapped_area functions Rik van Riel
2012-06-22 22:27 ` Russell King - ARM Linux
2012-06-23 17:50 ` Johannes Weiner
2012-06-21 21:57 ` [PATCH -mm v2 11/11] mm: remove SH " Rik van Riel
2012-06-25 2:11 ` Paul Mundt
2012-06-22 14:24 ` [PATCH -mm v2 00/11] mm: scalable and unified arch_get_unmapped_area John Stoffel
2012-06-22 21:47 ` Andrew Morton
2012-06-23 16:03 ` John Stoffel [this message]
2012-06-22 15:01 ` Johannes Weiner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20453.59620.255516.321417@quad.stoffel.home \
--to=john@stoffel.org \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=hannes@cmpxchg.org \
--cc=kosaki.motohiro@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=minchan@gmail.com \
--cc=peterz@infradead.org \
--cc=riel@surriel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox