linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: Hugh Dickins <hughd@google.com>,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	Gerald Schaefer <gerald.schaefer@de.ibm.com>,
	Steve Capper <steve.capper@linaro.org>,
	Dann Frazier <dann.frazier@canonical.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [PATCH] thp, mm: remove comments on serializion of THP split vs. gup_fast
Date: Thu, 10 Mar 2016 17:40:31 +0100	[thread overview]
Message-ID: <20160310164031.GM6375@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20160310163439.GS6356@twins.programming.kicks-ass.net>

On Thu, Mar 10, 2016 at 05:34:39PM +0100, Peter Zijlstra wrote:
> 
> > Then there's another issue with synchronize_sched(),
> > __get_user_pages_fast has to safe to run from irq (note the
> > local_irq_save instead of local_irq_disable) and KVM leverages it.
> 
> This is unchanged. synchronize_sched() serialized against anything that
> disables preemption, having IRQs disabled is very much included in that.
> 
> So there should be no problem running this from IRQ context.

Think of it this way: synchronize_sched() waits for every cpu to have
called schedule() at least once. If you're inside an IRQ handler, you
cannot call schedule(), therefore the RCU (sched) QS cannot progress and
any dereferences you make must stay valid.

> > Overall my main concern in switching x86 to RCU gup-fast is the
> > performance of synchronize_sched in large munmap pagetable teardown.
> 
> Normally, as already established by Martin, you should not actually ever
> encounter the sync_sched() call. Only under severe memory pressure, when
> the batch alloc in tlb_remove_table() fails is this ever an issue.
> 
> And at the point where such allocations fail, performance typically
> isn't a concern anymore.

Note, I'm not advocating switching x86 over (although it might be an
interested experiment), I just wanted to clarify some points I perceived
you were not entirely clear on.

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

  reply	other threads:[~2016-03-10 16:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-24 15:59 Kirill A. Shutemov
2016-02-24 17:50 ` Gerald Schaefer
2016-02-25 15:07   ` Kirill A. Shutemov
2016-02-26  6:50     ` Hugh Dickins
2016-02-26 11:06       ` Peter Zijlstra
2016-02-26 11:41         ` Martin Schwidefsky
2016-02-29  2:38           ` Hugh Dickins
2016-03-10 16:10       ` Andrea Arcangeli
2016-03-10 16:34         ` Peter Zijlstra
2016-03-10 16:40           ` Peter Zijlstra [this message]
2016-03-10 17:04           ` Andrea Arcangeli
2016-03-10 17:22             ` Andrea Arcangeli
2016-03-11  9:22               ` Peter Zijlstra

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=20160310164031.GM6375@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=dann.frazier@canonical.com \
    --cc=gerald.schaefer@de.ibm.com \
    --cc=hughd@google.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-mm@kvack.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=steve.capper@linaro.org \
    /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