linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Haggai Eran <haggaie@mellanox.com>
Cc: linux-mm@kvack.org, Andrea Arcangeli <aarcange@redhat.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>,
	Or Gerlitz <ogerlitz@mellanox.com>,
	Sagi Grimberg <sagig@mellanox.com>,
	Shachar Raindel <raindel@mellanox.com>,
	Liran Liss <liranl@mellanox.com>
Subject: Re: [PATCH V2 0/2] Enable clients to schedule in mmu_notifier methods
Date: Thu, 6 Sep 2012 13:08:14 -0700	[thread overview]
Message-ID: <20120906130814.af093f4d.akpm@linux-foundation.org> (raw)
In-Reply-To: <1346942095-23927-1-git-send-email-haggaie@mellanox.com>

On Thu,  6 Sep 2012 17:34:53 +0300
Haggai Eran <haggaie@mellanox.com> wrote:

>  include/linux/mmu_notifier.h | 47 --------------------------------------------
>  kernel/events/uprobes.c      |  5 +++++
>  mm/filemap_xip.c             |  4 +++-
>  mm/huge_memory.c             | 42 +++++++++++++++++++++++++++++++++------
>  mm/hugetlb.c                 | 21 ++++++++++++--------
>  mm/ksm.c                     | 21 ++++++++++++++++++--
>  mm/memory.c                  | 25 ++++++++++++++++++-----
>  mm/mmu_notifier.c            |  6 ------
>  mm/mremap.c                  |  8 ++++++--
>  mm/rmap.c                    | 18 ++++++++++++++---
>  10 files changed, 117 insertions(+), 80 deletions(-)

ho hum, spose so - the maintenance overhead does look to be a bit less now.

I use an ancient gcc. Do you see these with newer gcc?

mm/memory.c: In function 'do_wp_page':
mm/memory.c:2529: warning: 'mmun_start' may be used uninitialized in this function
mm/memory.c:2530: warning: 'mmun_end' may be used uninitialized in this function
mm/memory.c: In function 'copy_page_range':
mm/memory.c:1042: warning: 'mmun_start' may be used uninitialized in this function
mm/memory.c:1043: warning: 'mmun_end' may be used uninitialized in this function

The copy_page_range() one is a bit of a worry.  We're assuming that the
return value of is_cow_mapping(vma->vm_flags) will not change.  It
would be pretty alarming if it *were* to change, but exactly what
guarantees this?


I fiddled a couple of minor things:

From: Andrew Morton <akpm@linux-foundation.org>
Subject: mm-move-all-mmu-notifier-invocations-to-be-done-outside-the-pt-lock-fix

possible speed tweak in hugetlb_cow(), cleanups

Cc: Andrea Arcangeli <andrea@qumranet.com>
Cc: Avi Kivity <avi@redhat.com>
Cc: Christoph Lameter <cl@linux-foundation.org>
Cc: Haggai Eran <haggaie@mellanox.com>
Cc: Liran Liss <liranl@mellanox.com>
Cc: Or Gerlitz <ogerlitz@mellanox.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: Shachar Raindel <raindel@mellanox.com>
Cc: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/hugetlb.c |    2 +-
 mm/memory.c  |    3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

--- a/mm/hugetlb.c~mm-move-all-mmu-notifier-invocations-to-be-done-outside-the-pt-lock-fix
+++ a/mm/hugetlb.c
@@ -2616,7 +2616,7 @@ retry_avoidcopy:
 	__SetPageUptodate(new_page);
 
 	mmun_start = address & huge_page_mask(h);
-	mmun_end   = (address & huge_page_mask(h)) + huge_page_size(h);
+	mmun_end = mmun_start + huge_page_size(h);
 	mmu_notifier_invalidate_range_start(mm, mmun_start, mmun_end);
 	/*
 	 * Retake the page_table_lock to check for racing updates
--- a/mm/memory.c~mm-move-all-mmu-notifier-invocations-to-be-done-outside-the-pt-lock-fix
+++ a/mm/memory.c
@@ -1096,8 +1096,7 @@ int copy_page_range(struct mm_struct *ds
 	} while (dst_pgd++, src_pgd++, addr = next, addr != end);
 
 	if (is_cow_mapping(vma->vm_flags))
-		mmu_notifier_invalidate_range_end(src_mm, mmun_start,
-						  mmun_end);
+		mmu_notifier_invalidate_range_end(src_mm, mmun_start, mmun_end);
 	return ret;
 }
 

--
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>

  parent reply	other threads:[~2012-09-06 20:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-04  8:41 [PATCH V1 " Haggai Eran
2012-09-04  8:41 ` [PATCH V1 1/2] mm: Move all mmu notifier invocations to be done outside the PT lock Haggai Eran
2012-09-04 22:07   ` Andrew Morton
2012-09-06 14:34     ` [PATCH V2 0/2] Enable clients to schedule in mmu_notifier methods Haggai Eran
2012-09-06 14:34       ` [PATCH V2 1/2] mm: Move all mmu notifier invocations to be done outside the PT lock Haggai Eran
2012-09-06 14:34       ` [PATCH V2 2/2] mm: Wrap calls to set_pte_at_notify with invalidate_range_start and invalidate_range_end Haggai Eran
2012-09-06 20:08       ` Andrew Morton [this message]
2012-09-04  8:41 ` [PATCH V1 " Haggai Eran
2012-09-04 22:07   ` Andrew Morton
2012-09-04 22:06 ` [PATCH V1 0/2] Enable clients to schedule in mmu_notifier methods Andrew Morton
2012-09-05 12:55   ` Avi Kivity
2012-09-05 14:01   ` Haggai Eran

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=20120906130814.af093f4d.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=aarcange@redhat.com \
    --cc=haggaie@mellanox.com \
    --cc=linux-mm@kvack.org \
    --cc=liranl@mellanox.com \
    --cc=ogerlitz@mellanox.com \
    --cc=raindel@mellanox.com \
    --cc=sagig@mellanox.com \
    --cc=xiaoguangrong@linux.vnet.ibm.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