On Fri, Dec 14, 2012 at 6:17 PM, Andy Lutomirski l...@amacapital.net wrote:
This is a serious cause of mmap_sem contention. MAP_POPULATE
and MCL_FUTURE, in particular, are disastrous in multithreaded programs.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
Changes from v1:
The
On Sun, Dec 16, 2012 at 10:05 AM, Andy Lutomirski l...@amacapital.net wrote:
On Sun, Dec 16, 2012 at 4:39 AM, Michel Lespinasse wal...@google.com wrote:
My main concern is that just downgrading the mmap_sem only hides the
problem: as soon as a writer gets queued on that mmap_sem,
reader/writer
2012 at 9:40 PM, Michel Lespinasse wrote:
>>> On Thu, Nov 22, 2012 at 9:49 PM, Michel Lespinasse
>>> wrote:
>>>> On Thu, Nov 22, 2012 at 9:14 AM, Sasha Levin
>>>> wrote:
>>>>> The following patch fixed the problem for me:
>>>
...@gmail.com wrote:
On Sat, Nov 24, 2012 at 9:40 PM, Michel Lespinasse wal...@google.com wrote:
On Thu, Nov 22, 2012 at 9:49 PM, Michel Lespinasse wal...@google.com
wrote:
On Thu, Nov 22, 2012 at 9:14 AM, Sasha Levin sasha.le...@oracle.com
wrote:
The following patch fixed the problem for me:
diff
On Sun, Dec 2, 2012 at 7:12 AM, Ingo Molnar wrote:
> Subject: [PATCH] mm/rmap, migration: Make rmap_walk_anon() and
> try_to_unmap_anon() more scalable
>
> rmap_walk_anon() and try_to_unmap_anon() appears to be too
> careful about locking the anon vma: while it needs protection
> against anon
ing stack expansion is
expected to be small: glibc doesn't use expandable stacks for the
threads it creates, so having multiple growable stacks is actually
uncommon and we don't expect the page table lock to get bounced
between threads.
Signed-off-by: Michel Lespinasse
---
mm/mmap.c |
we mutex_lock()ed we'll now down_write().
Looks good.
Reviewed-by: Michel Lespinasse
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mes
on_vma)
> {
> down_write(_vma->root->rwsem);
> }
> @@ -128,6 +128,17 @@ static inline void anon_vma_unlock(struct anon_vma
> *anon_vma)
> up_write(_vma->root->rwsem);
> }
And as Rik noticed, you forgot to rename anon_vma_unlock() too.
But re
On Mon, Dec 3, 2012 at 6:17 AM, Mel Gorman wrote:
> On Sat, Dec 01, 2012 at 09:15:38PM +0100, Ingo Molnar wrote:
>> @@ -732,7 +732,7 @@ static int page_referenced_anon(struct p
>> struct anon_vma_chain *avc;
>> int referenced = 0;
>>
>> - anon_vma = page_lock_anon_vma(page);
>> +
On Mon, Dec 3, 2012 at 6:17 AM, Mel Gorman mgor...@suse.de wrote:
On Sat, Dec 01, 2012 at 09:15:38PM +0100, Ingo Molnar wrote:
@@ -732,7 +732,7 @@ static int page_referenced_anon(struct p
struct anon_vma_chain *avc;
int referenced = 0;
- anon_vma = page_lock_anon_vma(page);
*anon_vma)
up_write(anon_vma-root-rwsem);
}
And as Rik noticed, you forgot to rename anon_vma_unlock() too.
But really, this is nitpicking. I like the idea behind the patch, and
after giving it a close look, I couldn't find anything wrong with it.
Reviewed-by: Michel Lespinasse wal
mutex_lock()ed we'll now down_write().
Looks good.
Reviewed-by: Michel Lespinasse wal...@google.com
--
Michel Walken Lespinasse
A program is never fully debugged until the last user dies.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
stack expansion is
expected to be small: glibc doesn't use expandable stacks for the
threads it creates, so having multiple growable stacks is actually
uncommon and we don't expect the page table lock to get bounced
between threads.
Signed-off-by: Michel Lespinasse wal...@google.com
---
mm/mmap.c
On Sun, Dec 2, 2012 at 7:12 AM, Ingo Molnar mi...@kernel.org wrote:
Subject: [PATCH] mm/rmap, migration: Make rmap_walk_anon() and
try_to_unmap_anon() more scalable
rmap_walk_anon() and try_to_unmap_anon() appears to be too
careful about locking the anon vma: while it needs protection
On Mon, Dec 3, 2012 at 3:01 PM, Andrew Morton wrote:
> On Fri, 30 Nov 2012 22:56:27 -0800
> Michel Lespinasse wrote:
>
>> expand_stack() runs with a shared mmap_sem lock. Because of this, there
>> could be multiple concurrent stack expansions in the same mm, which
On Mon, Dec 3, 2012 at 3:01 PM, Andrew Morton a...@linux-foundation.org wrote:
On Fri, 30 Nov 2012 22:56:27 -0800
Michel Lespinasse wal...@google.com wrote:
expand_stack() runs with a shared mmap_sem lock. Because of this, there
could be multiple concurrent stack expansions in the same mm
mas in a given mm would share the same anon_vma, which we
already lock here. However this turned out to be difficult - all of the
schemes I tried for refcounting the growable anon_vma and clearing
turned out ugly. So, I'm now proposing only the minimal fix.
Signed-off-by: Michel Lespinasse
---
mm/mma
in a given mm would share the same anon_vma, which we
already lock here. However this turned out to be difficult - all of the
schemes I tried for refcounting the growable anon_vma and clearing
turned out ugly. So, I'm now proposing only the minimal fix.
Signed-off-by: Michel Lespinasse wal...@google.com
On Mon, Nov 26, 2012 at 5:16 PM, Sasha Levin wrote:
> I've built today's -next, and got the following BUG pretty quickly (2-3
> hours):
>
> [ 1556.479284] BUG: unable to handle kernel paging request at 00412000
> [ 1556.480036] IP: [] validate_mm+0x34/0x130
> [ 1556.480036] PGD 31739067
On Mon, Nov 26, 2012 at 5:16 PM, Sasha Levin levinsasha...@gmail.com wrote:
I've built today's -next, and got the following BUG pretty quickly (2-3
hours):
[ 1556.479284] BUG: unable to handle kernel paging request at 00412000
[ 1556.480036] IP: [81238184]
Since nothing depends on the max_high field values anymore, we can just
remove the field and the code that was used to maintain it.
Signed-off-by: Michel Lespinasse
---
tools/kvm/include/kvm/rbtree-interval.h | 13 ---
tools/kvm/util/rbtree-interval.c| 58
As the rbtree intervals are not overlapping, rb_int_search_single can
trivially be implemented without making use of the max_high field.
Signed-off-by: Michel Lespinasse
---
tools/kvm/util/rbtree-interval.c | 18 +-
1 files changed, 5 insertions(+), 13 deletions(-)
diff
trigger an
integer overflow which would break the rbtree ordering.
Signed-off-by: Michel Lespinasse
---
tools/kvm/util/rbtree-interval.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/kvm/util/rbtree-interval.c b/tools/kvm/util/rbtree-interval.c
index
On Thu, Nov 22, 2012 at 9:49 PM, Michel Lespinasse wrote:
> On Thu, Nov 22, 2012 at 9:14 AM, Sasha Levin wrote:
>> The following patch fixed the problem for me:
>>
>> diff --git a/include/linux/rbtree_augmented.h
>> b/include/linux/rbtree_augmented.h
>&
On Thu, Nov 22, 2012 at 9:49 PM, Michel Lespinasse wal...@google.com wrote:
On Thu, Nov 22, 2012 at 9:14 AM, Sasha Levin sasha.le...@oracle.com wrote:
The following patch fixed the problem for me:
diff --git a/include/linux/rbtree_augmented.h
b/include/linux/rbtree_augmented.h
index 214caa3
trigger an
integer overflow which would break the rbtree ordering.
Signed-off-by: Michel Lespinasse wal...@google.com
---
tools/kvm/util/rbtree-interval.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/kvm/util/rbtree-interval.c b/tools/kvm/util/rbtree
As the rbtree intervals are not overlapping, rb_int_search_single can
trivially be implemented without making use of the max_high field.
Signed-off-by: Michel Lespinasse wal...@google.com
---
tools/kvm/util/rbtree-interval.c | 18 +-
1 files changed, 5 insertions(+), 13
Since nothing depends on the max_high field values anymore, we can just
remove the field and the code that was used to maintain it.
Signed-off-by: Michel Lespinasse wal...@google.com
---
tools/kvm/include/kvm/rbtree-interval.h | 13 ---
tools/kvm/util/rbtree-interval.c| 58
On Thu, Nov 22, 2012 at 9:14 AM, Sasha Levin wrote:
> Hi Michel,
>
> I've noticed a bug regarding search of ioports in the KVM tool. Since the KVM
> tool is
> using kernel's augmented rbtree implementation to represent an interval
> rbtree I dug a
> bit into the new implementation in the
On Thu, Nov 22, 2012 at 9:14 AM, Sasha Levin sasha.le...@oracle.com wrote:
Hi Michel,
I've noticed a bug regarding search of ioports in the KVM tool. Since the KVM
tool is
using kernel's augmented rbtree implementation to represent an interval
rbtree I dug a
bit into the new
gt; include/linux/compiler.h | 32 +--
> 5 files changed, 76 insertions(+), 42 deletions(-)
>
> Changes in v6:
> o Remove extraneous double negation
> o Fixed faulty macro expansion in last patch
Acked-by: Michel Lespinasse on the entire v6 series
include/linux/compiler.h | 32 +--
5 files changed, 76 insertions(+), 42 deletions(-)
Changes in v6:
o Remove extraneous double negation
o Fixed faulty macro expansion in last patch
Acked-by: Michel Lespinasse wal...@google.com on the entire v6 series
On Sat, Nov 17, 2012 at 1:53 PM, Shentino wrote:
> I'm actually curious if the architecture docs/software developer
> manuals for IA-32 mandate any TLB invalidations on a #PF
>
> Is there any official vendor documentation on the subject?
Yes. Quoting a prior email:
Actually, it is architected
On Sat, Nov 17, 2012 at 1:53 PM, Shentino shent...@gmail.com wrote:
I'm actually curious if the architecture docs/software developer
manuals for IA-32 mandate any TLB invalidations on a #PF
Is there any official vendor documentation on the subject?
Yes. Quoting a prior email:
Actually, it is
On Fri, Nov 9, 2012 at 6:13 AM, Sasha Levin wrote:
> While fuzzing with trinity inside a KVM tools (lkvm) guest, using today's
> -next
> kernel, I'm getting these:
>
> [ 117.007714] free gap 7fba0dd1c000, correct 7fba0dcfb000
> [ 117.019773] map_count 750 rb -1
> [ 117.028362] [
ure vma_rb_erase() runs before there are any
such stale rb_subtree_gap values in the rbtree.
(I don't know of a reproduceable test case for this particular issue)
Signed-off-by: Michel Lespinasse
---
mm/mmap.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/mmap.c b
to propagate the rb_subtree_gap updates as high up as necessary.
Signed-off-by: Michel Lespinasse
---
mm/mmap.c | 88 ++---
1 files changed, 55 insertions(+), 33 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index c60ac9fe2d7e..408d330aca6c
the problem and to Hugh Dickins
for coming up with a simpler test case)
Reported-by: Sasha Levin
Signed-off-by: Michel Lespinasse
---
mm/mmap.c | 27 +++
1 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index 619b280505fe..14859b999a9f
that
the node being erased doesn't need to have an up to date rb_subtree_gap.
These 3 patches apply on top of the stack I previously sent (or equally,
on top of the last published mmotm).
Michel Lespinasse (3):
mm: ensure safe rb_subtree_gap update when inserting new VMA
mm: ensure safe rb_subtree_gap
that
the node being erased doesn't need to have an up to date rb_subtree_gap.
These 3 patches apply on top of the stack I previously sent (or equally,
on top of the last published mmotm).
Michel Lespinasse (3):
mm: ensure safe rb_subtree_gap update when inserting new VMA
mm: ensure safe rb_subtree_gap
the problem and to Hugh Dickins
for coming up with a simpler test case)
Reported-by: Sasha Levin sasha.le...@oracle.com
Signed-off-by: Michel Lespinasse wal...@google.com
---
mm/mmap.c | 27 +++
1 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/mm/mmap.c b/mm
to propagate the rb_subtree_gap updates as high up as necessary.
Signed-off-by: Michel Lespinasse wal...@google.com
---
mm/mmap.c | 88 ++---
1 files changed, 55 insertions(+), 33 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index c60ac9fe2d7e
vma_rb_erase() runs before there are any
such stale rb_subtree_gap values in the rbtree.
(I don't know of a reproduceable test case for this particular issue)
Signed-off-by: Michel Lespinasse wal...@google.com
---
mm/mmap.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git
On Fri, Nov 9, 2012 at 6:13 AM, Sasha Levin levinsasha...@gmail.com wrote:
While fuzzing with trinity inside a KVM tools (lkvm) guest, using today's
-next
kernel, I'm getting these:
[ 117.007714] free gap 7fba0dd1c000, correct 7fba0dcfb000
[ 117.019773] map_count 750 rb -1
[ 117.028362]
On Fri, Nov 9, 2012 at 11:33 PM, Al Viro wrote:
> Could you verify that this on top of for-next gets the things working again?
> It's a very lazy way to deal with that (we don't want to bother with
> restoring extras, at the very least), but the rest can go separately (and
> is shared with
On Fri, Nov 9, 2012 at 11:33 PM, Al Viro v...@zeniv.linux.org.uk wrote:
Could you verify that this on top of for-next gets the things working again?
It's a very lazy way to deal with that (we don't want to bother with
restoring extras, at the very least), but the rest can go separately (and
is
On Fri, Nov 9, 2012 at 9:33 PM, Al Viro wrote:
> On Fri, Nov 09, 2012 at 08:57:58PM -0800, Michel Lespinasse wrote:
>> On Fri, Nov 9, 2012 at 8:51 PM, Al Viro wrote:
>> > On Fri, Nov 09, 2012 at 08:36:53PM -0800, Michel Lespinasse wrote:
>> >> Hi,
>> >>
On Fri, Nov 9, 2012 at 8:51 PM, Al Viro wrote:
> On Fri, Nov 09, 2012 at 08:36:53PM -0800, Michel Lespinasse wrote:
>> Hi,
>>
>> I'm having an issue booting current linux-next kernels on my test
>> machines. Userspace crashes when it's supposed to pivot to the roo
Hi,
I'm having an issue booting current linux-next kernels on my test
machines. Userspace crashes when it's supposed to pivot to the rootfs.
With the loglevel=8 kernel parameter, the last messages I see are:
Checking root filesystem in pivot_root init.
[6.252717] usb 2-1: link
Hi,
I'm having an issue booting current linux-next kernels on my test
machines. Userspace crashes when it's supposed to pivot to the rootfs.
With the loglevel=8 kernel parameter, the last messages I see are:
Checking root filesystem in pivot_root init.
[6.252717] usb 2-1: link
On Fri, Nov 9, 2012 at 8:51 PM, Al Viro v...@zeniv.linux.org.uk wrote:
On Fri, Nov 09, 2012 at 08:36:53PM -0800, Michel Lespinasse wrote:
Hi,
I'm having an issue booting current linux-next kernels on my test
machines. Userspace crashes when it's supposed to pivot to the rootfs
On Fri, Nov 9, 2012 at 9:33 PM, Al Viro v...@zeniv.linux.org.uk wrote:
On Fri, Nov 09, 2012 at 08:57:58PM -0800, Michel Lespinasse wrote:
On Fri, Nov 9, 2012 at 8:51 PM, Al Viro v...@zeniv.linux.org.uk wrote:
On Fri, Nov 09, 2012 at 08:36:53PM -0800, Michel Lespinasse wrote:
Hi,
I'm
> arch/tile/mm/hugetlbpage.c:256:20: note: each undeclared identifier is
> reported only once for each function it appears in
commit 86234092170b43771c3f6257cb320ff6e2c10c52
Author: Michel Lespinasse
Date: Thu Nov 8 22:13:58 2012 -0800
fix mm: use vm_unmapped_area() in hugetlbfs
e for
> each function it appears in
commit 34550b95185c1ecfa8882664744c14edda385868
Author: Michel Lespinasse
Date: Thu Nov 8 22:14:34 2012 -0800
fix mm: augment vma rbtree with rb_subtree_gap
diff --git a/mm/mmap.c b/mm/mmap.c
index d12c69eaf23f..0b8f9d83e2e2 100644
--- a/mm/mmap.c
+++ b
ning: unused variable 'start_addr'
> [-Wunused-variable]
>
> Introduced by commit "mm: use vm_unmapped_area() on arm architecture".
Sorry for the mistakes. The following changes should fix what's been reported
so far.
commit 1c98949798ce7a1d4a910775623e1830cf88a92c
Author: Miche
'
[-Wunused-variable]
Introduced by commit mm: use vm_unmapped_area() on arm architecture.
Sorry for the mistakes. The following changes should fix what's been reported
so far.
commit 1c98949798ce7a1d4a910775623e1830cf88a92c
Author: Michel Lespinasse wal...@google.com
Date: Thu Nov 8 20:26
34550b95185c1ecfa8882664744c14edda385868
Author: Michel Lespinasse wal...@google.com
Date: Thu Nov 8 22:14:34 2012 -0800
fix mm: augment vma rbtree with rb_subtree_gap
diff --git a/mm/mmap.c b/mm/mmap.c
index d12c69eaf23f..0b8f9d83e2e2 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2032,7 +2032,7
: each undeclared identifier is
reported only once for each function it appears in
commit 86234092170b43771c3f6257cb320ff6e2c10c52
Author: Michel Lespinasse wal...@google.com
Date: Thu Nov 8 22:13:58 2012 -0800
fix mm: use vm_unmapped_area() in hugetlbfs on tile architecture
diff --git a/arch
On Tue, Nov 6, 2012 at 12:24 AM, Michel Lespinasse wrote:
> On Mon, Nov 5, 2012 at 5:41 AM, Michel Lespinasse wrote:
>> On Sun, Nov 4, 2012 at 8:44 PM, Michel Lespinasse wrote:
>>> On Sun, Nov 4, 2012 at 8:14 PM, Bob Liu wrote:
>>>> Hmm, I attached a simp
On Mon, Nov 5, 2012 at 5:41 AM, Michel Lespinasse wrote:
> On Sun, Nov 4, 2012 at 8:44 PM, Michel Lespinasse wrote:
>> On Sun, Nov 4, 2012 at 8:14 PM, Bob Liu wrote:
>>> Hmm, I attached a simple fix patch.
>>
>> Reviewed-by: Michel Lespinasse
>> (also ran s
Adding Sasha and Bob, which I forgot to CC in the original message.
On Mon, Nov 5, 2012 at 3:06 PM, Rik van Riel wrote:
> On 11/05/2012 05:46 PM, Michel Lespinasse wrote:
>>
>> Iterate vma->anon_vma_chain without anon_vma_lock may cause NULL ptr deref
>> in
>>
Adding Sasha and Bob, which I forgot to CC in the original message.
On Mon, Nov 5, 2012 at 3:06 PM, Rik van Riel r...@redhat.com wrote:
On 11/05/2012 05:46 PM, Michel Lespinasse wrote:
Iterate vma-anon_vma_chain without anon_vma_lock may cause NULL ptr deref
in
anon_vma_interval_tree_verify
On Mon, Nov 5, 2012 at 5:41 AM, Michel Lespinasse wal...@google.com wrote:
On Sun, Nov 4, 2012 at 8:44 PM, Michel Lespinasse wal...@google.com wrote:
On Sun, Nov 4, 2012 at 8:14 PM, Bob Liu lliu...@gmail.com wrote:
Hmm, I attached a simple fix patch.
Reviewed-by: Michel Lespinasse wal
On Tue, Nov 6, 2012 at 12:24 AM, Michel Lespinasse wal...@google.com wrote:
On Mon, Nov 5, 2012 at 5:41 AM, Michel Lespinasse wal...@google.com wrote:
On Sun, Nov 4, 2012 at 8:44 PM, Michel Lespinasse wal...@google.com wrote:
On Sun, Nov 4, 2012 at 8:14 PM, Bob Liu lliu...@gmail.com wrote:
Hmm
On Mon, Nov 5, 2012 at 5:25 PM, David Miller wrote:
> From: Michel Lespinasse
> Date: Mon, 5 Nov 2012 14:47:12 -0800
>
>> Update the sparc32 arch_get_unmapped_area function to make use of
>> vm_unmapped_area() instead of implementing a brute force search.
>>
>>
: Bob Liu
Signed-off-by: Michel Lespinasse
---
mm/mmap.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index 2d942353d681..9a796c41e7d9 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -334,8 +334,10 @@ void validate_mm(struct mm_struct *mm)
duplicating the brute force algorithm all over the place. There is
still a bit of repetition between various implementations of
arch_get_unmapped_area[_topdown] functions that could probably be
simplified somehow, but I feel we can keep that for a later step...
Michel Lespinasse (15):
mm: add
tree walk is in the first cache line.
Signed-off-by: Michel Lespinasse
Signed-off-by: Rik van Riel
---
include/linux/mm_types.h | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 94fa52b28ee8..528da4abf8ee
gap length
- low/high address limits that the gap must fit into
- alignment mask and offset
Also update the generic arch_get_unmapped_area[_topdown] functions to
make use of vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
Reviewed-by: Rik van
A mmaps the file with pgoff 0, and program B mmaps the
file with pgoff 1. The old code would align the mmaps, resulting in
misaligned pages:
A: 0123
B: 123
After this patch, they are aligned so the pages line up:
A: 0123
B: 123
Signed-off-by: Michel Lespinasse
Proposed-by: Rik van Riel
Update the i386 hugetlb_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
---
arch/x86/mm/hugetlbpage.c | 130 +
1 files changed, 25 insertions(+), 105
Update the arm arch_get_unmapped_area[_topdown] functions to make
use of vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
---
arch/arm/mm/mmap.c | 119 ++--
1 files changed, 23 insertions(+), 96
Update the hugetlb_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
---
fs/hugetlbfs/inode.c | 42 --
1 files changed, 8 insertions(+), 34 deletions(-)
diff
Update the x86_64 arch_get_unmapped_area[_topdown] functions to make
use of vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
Reviewed-by: Rik van Riel
---
arch/x86/include/asm/elf.h |6 +-
arch/x86/kernel/sys_x86_64.c | 151
When CONFIG_DEBUG_VM_RB is enabled, check that rb_subtree_gap is
correctly set for every vma and that mm->highest_vm_end is also correct.
Also add an explicit 'bug' variable to track if browse_rb() detected any
invalid condition.
Signed-off-by: Michel Lespinasse
Reviewed-by: Rik van R
eck if the following gap is suitable.
This does have the potential to make unmapping VMAs more expensive,
especially for processes with very large numbers of VMAs, where the
VMA rbtree can grow quite deep.
Signed-off-by: Michel Lespinasse
Reviewed-by: Rik van Riel
---
include/linux/mm_types.
Update the mips arch_get_unmapped_area[_topdown] functions to make
use of vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
---
arch/mips/mm/mmap.c | 99 +--
1 files changed, 17 insertions(+), 82
Update the sparc64 arch_get_unmapped_area[_topdown] functions to make
use of vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
---
arch/sparc/kernel/sys_sparc_64.c | 132 +-
1 files changed, 30 insertions
Update the sparc64 hugetlb_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
---
arch/sparc/mm/hugetlbpage.c | 123 ++
1 files changed, 30 insertions(+), 93
Update the sh arch_get_unmapped_area[_topdown] functions to make
use of vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
---
arch/sh/mm/mmap.c | 126 ++---
1 files changed, 24 insertions(+), 102
Update the tile hugetlb_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
---
arch/tile/mm/hugetlbpage.c | 139
1 files changed, 25 insertions(+), 114
Update the sparc32 arch_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
---
arch/sparc/kernel/sys_sparc_32.c | 24 +---
1 files changed, 9 insertions(+), 15 deletions(-)
diff
On Sun, Nov 4, 2012 at 8:44 PM, Michel Lespinasse wrote:
> On Sun, Nov 4, 2012 at 8:14 PM, Bob Liu wrote:
>> Hmm, I attached a simple fix patch.
>
> Reviewed-by: Michel Lespinasse
> (also ran some tests with it, but I could never reproduce the original
> issue an
On Sun, Nov 4, 2012 at 8:44 PM, Michel Lespinasse wal...@google.com wrote:
On Sun, Nov 4, 2012 at 8:14 PM, Bob Liu lliu...@gmail.com wrote:
Hmm, I attached a simple fix patch.
Reviewed-by: Michel Lespinasse wal...@google.com
(also ran some tests with it, but I could never reproduce
Update the sparc32 arch_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse wal...@google.com
---
arch/sparc/kernel/sys_sparc_32.c | 24 +---
1 files changed, 9 insertions(+), 15
Update the sh arch_get_unmapped_area[_topdown] functions to make
use of vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse wal...@google.com
---
arch/sh/mm/mmap.c | 126 ++---
1 files changed, 24
Update the tile hugetlb_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse wal...@google.com
---
arch/tile/mm/hugetlbpage.c | 139
1 files changed, 25
Update the sparc64 hugetlb_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse wal...@google.com
---
arch/sparc/mm/hugetlbpage.c | 123 ++
1 files changed, 30
Update the sparc64 arch_get_unmapped_area[_topdown] functions to make
use of vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse wal...@google.com
---
arch/sparc/kernel/sys_sparc_64.c | 132 +-
1 files changed
Update the mips arch_get_unmapped_area[_topdown] functions to make
use of vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse wal...@google.com
---
arch/mips/mm/mmap.c | 99 +--
1 files changed, 17
is suitable.
This does have the potential to make unmapping VMAs more expensive,
especially for processes with very large numbers of VMAs, where the
VMA rbtree can grow quite deep.
Signed-off-by: Michel Lespinasse wal...@google.com
Reviewed-by: Rik van Riel r...@redhat.com
---
include/linux/mm_types.h
When CONFIG_DEBUG_VM_RB is enabled, check that rb_subtree_gap is
correctly set for every vma and that mm-highest_vm_end is also correct.
Also add an explicit 'bug' variable to track if browse_rb() detected any
invalid condition.
Signed-off-by: Michel Lespinasse wal...@google.com
Reviewed-by: Rik
Update the x86_64 arch_get_unmapped_area[_topdown] functions to make
use of vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse wal...@google.com
Reviewed-by: Rik van Riel r...@redhat.com
---
arch/x86/include/asm/elf.h |6 +-
arch/x86/kernel
Update the hugetlb_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse wal...@google.com
---
fs/hugetlbfs/inode.c | 42 --
1 files changed, 8 insertions(+), 34
Update the i386 hugetlb_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse wal...@google.com
---
arch/x86/mm/hugetlbpage.c | 130 +
1 files changed, 25
Update the arm arch_get_unmapped_area[_topdown] functions to make
use of vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse wal...@google.com
---
arch/arm/mm/mmap.c | 119 ++--
1 files changed, 23
A mmaps the file with pgoff 0, and program B mmaps the
file with pgoff 1. The old code would align the mmaps, resulting in
misaligned pages:
A: 0123
B: 123
After this patch, they are aligned so the pages line up:
A: 0123
B: 123
Signed-off-by: Michel Lespinasse wal...@google.com
Proposed
gap length
- low/high address limits that the gap must fit into
- alignment mask and offset
Also update the generic arch_get_unmapped_area[_topdown] functions to
make use of vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse wal...@google.com
to do a VMA tree walk is in the first cache line.
Signed-off-by: Michel Lespinasse wal...@google.com
Signed-off-by: Rik van Riel r...@redhat.com
---
include/linux/mm_types.h | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/include/linux/mm_types.h b/include
duplicating the brute force algorithm all over the place. There is
still a bit of repetition between various implementations of
arch_get_unmapped_area[_topdown] functions that could probably be
simplified somehow, but I feel we can keep that for a later step...
Michel Lespinasse (15):
mm: add
701 - 800 of 1086 matches
Mail list logo
