From: Andrea Arcangeli <aarcange@redhat.com>
To: Robin Holt <holt@sgi.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Jack Steiner <steiner@sgi.com>,
linux-mm@kvack.org
Subject: Re: [RFP-V2 0/3] Make mmu_notifier_invalidate_range_start able to sleep.
Date: Tue, 2 Feb 2010 21:17:19 +0100 [thread overview]
Message-ID: <20100202201718.GQ4135@random.random> (raw)
In-Reply-To: <20100202165903.GN6616@sgi.com>
On Tue, Feb 02, 2010 at 10:59:03AM -0600, Robin Holt wrote:
> But we don't use the vma for anything. The _invalidate_range_start/end
> is using the mm. XPMEM and GRU don't use the vma. Does KVM? Since it
> isn't passed in, I would expect that anybody trying to use the vma is
> going to have to do a find_vma themselves. Did I miss something?
No sorry, we are passing down the mm not the vma so it should be ok already.
> Is this better?
>
> static int unmap_mapping_range_vma(struct vm_area_struct *vma,
> ...
> if (need_unlocked_invalidate) {
> mm = vma->vm_mm;
> atomic_inc(&mm->mm_count);
> }
> spin_unlock(details->i_mmap_lock);
> if (need_unlocked_invalidate) {
> /*
> * zap_page_range failed to make any progress because the
> * mmu_notifier_invalidate_range_start was called atomically
> * while the callee needed to sleep. In that event, we
> * make the callout while the i_mmap_lock is released.
> */
> mmu_notifier_invalidate_range_start(mm, start_addr, end_addr, 0);
> mmu_notifier_invalidate_range_end(mm, start_addr, end_addr);
> mmdrop(mm);
> }
Yes with mm_count it's better and this way it should be safe. I think
it's an ok tradeoff, hopefully then nobody will ask to schedule in
->invalidate_page. Still it'd be interesting (back to Andrew's
argument) to understand what is fundamentally different that you are
ok not to schedule in ->invalidate_page but you absolutely need it
here. And yes this will break also my transparent hugepage patch that
can't schedule inside the anon_vma->lock and uses the range calls to
be safer (then maybe we can require the mmu notifier users to check
PageTransHuge against the pages and handle the invalidate through
->invalidate_page or we can add ->invalidate_transhuge_page.
--
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:[~2010-02-02 20:17 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20100202040145.555474000@alcatraz.americas.sgi.com>
2010-02-02 4:01 ` [RFP-V2 1/3] Have mmu_notifiers use SRCU so they may safely schedule Robin Holt
2010-02-02 4:01 ` [RFP-V2 2/3] Fix unmap_vma() bug related to mmu_notifiers Robin Holt
2010-02-02 4:01 ` [RFP-V2 3/3] Make mmu_notifier_invalidate_range_start able to sleep Robin Holt
2010-02-02 8:09 ` [RFP-V2 0/3] " Christoph Hellwig
2010-02-02 12:59 ` Andrea Arcangeli
2010-02-02 13:13 ` Andrea Arcangeli
2010-02-02 13:29 ` Robin Holt
2010-02-02 13:40 ` Andrea Arcangeli
2010-02-02 13:51 ` Robin Holt
2010-02-02 14:10 ` Andrea Arcangeli
2010-02-02 14:21 ` Robin Holt
2010-02-02 14:59 ` Andrea Arcangeli
2010-02-02 15:21 ` Robin Holt
2010-02-02 16:01 ` Andrea Arcangeli
2010-02-02 16:39 ` Robin Holt
2010-02-02 16:52 ` Andrea Arcangeli
2010-02-02 16:59 ` Robin Holt
2010-02-02 17:31 ` Robin Holt
2010-02-02 20:27 ` Andrea Arcangeli
2010-02-02 20:17 ` Andrea Arcangeli [this message]
2010-02-03 0:48 ` Robin Holt
2010-02-03 17:14 ` Andrea Arcangeli
2010-02-03 17:18 ` Andrea Arcangeli
2010-02-03 19:54 ` Robin Holt
2010-02-02 13:23 ` Robin Holt
2010-02-02 13:35 ` Robin Holt
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=20100202201718.GQ4135@random.random \
--to=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=hch@infradead.org \
--cc=holt@sgi.com \
--cc=linux-mm@kvack.org \
--cc=steiner@sgi.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.