From: Peter Zijlstra <peterz@infradead.org>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: "Paul E. McKenney" <paulmck@linux.ibm.com>,
Ingo Molnar <mingo@kernel.org>,
linux-kernel@vger.kernel.org, Oleg Nesterov <oleg@redhat.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Russell King - ARM Linux admin <linux@armlinux.org.uk>,
Chris Metcalf <cmetcalf@ezchip.com>,
Christoph Lameter <cl@linux.com>, Kirill Tkhai <tkhai@yandex.ru>,
Mike Galbraith <efault@gmx.de>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC PATCH 3/4] Cleanup: sched/membarrier: only sync_core before usermode for same mm
Date: Fri, 6 Sep 2019 09:41:04 +0200 [thread overview]
Message-ID: <20190906074104.GT2349@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20190906031300.1647-4-mathieu.desnoyers@efficios.com>
On Thu, Sep 05, 2019 at 11:12:59PM -0400, Mathieu Desnoyers wrote:
> When the prev and next task's mm change, switch_mm() provides the core
> serializing guarantees before returning to usermode. The only case
> where an explicit core serialization is needed is when the scheduler
> keeps the same mm for prev and next.
>
> Suggested-by: Oleg Nesterov <oleg@redhat.com>
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> Cc: "Paul E. McKenney" <paulmck@linux.ibm.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Oleg Nesterov <oleg@redhat.com>
> Cc: "Eric W. Biederman" <ebiederm@xmission.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> Cc: Chris Metcalf <cmetcalf@ezchip.com>
> Cc: Christoph Lameter <cl@linux.com>
> Cc: Kirill Tkhai <tkhai@yandex.ru>
> Cc: Mike Galbraith <efault@gmx.de>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@kernel.org>
> ---
> include/linux/sched/mm.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
> index 4a7944078cc3..8557ec664213 100644
> --- a/include/linux/sched/mm.h
> +++ b/include/linux/sched/mm.h
> @@ -362,6 +362,8 @@ enum {
>
> static inline void membarrier_mm_sync_core_before_usermode(struct mm_struct *mm)
> {
> + if (current->mm != mm)
> + return;
> if (likely(!(atomic_read(&mm->membarrier_state) &
> MEMBARRIER_STATE_PRIVATE_EXPEDITED_SYNC_CORE)))
> return;
So SYNC_CORE is about I$ coherency and funny thing like that. Now it
seems 'natural' that if we flip the address space, that I$ also gets
wiped/updated, because the whole text mapping changes.
But did we just assume that, or did we verify the truth of this? (I'm
just being paranoid here)
next prev parent reply other threads:[~2019-09-06 7:41 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-06 3:12 [RFC PATCH 0/4] Membarrier fixes/cleanups Mathieu Desnoyers
2019-09-06 3:12 ` [RFC PATCH 1/4] Fix: sched/membarrier: private expedited registration check Mathieu Desnoyers
2019-09-06 3:12 ` [RFC PATCH 2/4] Cleanup: sched/membarrier: remove redundant check Mathieu Desnoyers
2019-09-06 3:12 ` [RFC PATCH 3/4] Cleanup: sched/membarrier: only sync_core before usermode for same mm Mathieu Desnoyers
2019-09-06 7:41 ` Peter Zijlstra [this message]
2019-09-06 13:40 ` Mathieu Desnoyers
2019-09-06 3:13 ` [RFC PATCH 4/4] Fix: sched/membarrier: p->mm->membarrier_state racy load Mathieu Desnoyers
2019-09-06 8:23 ` Peter Zijlstra
2019-09-08 13:49 ` [RFC PATCH 4/4] Fix: sched/membarrier: p->mm->membarrier_state racy load (v2) Mathieu Desnoyers
2019-09-08 16:51 ` Linus Torvalds
2019-09-10 9:48 ` Mathieu Desnoyers
2019-09-12 13:48 ` Will Deacon
2019-09-12 14:24 ` Linus Torvalds
2019-09-12 15:47 ` Will Deacon
2019-09-13 14:22 ` Mathieu Desnoyers
2019-09-19 16:26 ` Will Deacon
2019-09-19 17:33 ` Mathieu Desnoyers
2019-09-09 11:00 ` Oleg Nesterov
2019-09-13 15:20 ` Mathieu Desnoyers
2019-09-13 16:04 ` Oleg Nesterov
2019-09-13 17:07 ` Mathieu Desnoyers
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=20190906074104.GT2349@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=cl@linux.com \
--cc=cmetcalf@ezchip.com \
--cc=ebiederm@xmission.com \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=paulmck@linux.ibm.com \
--cc=tglx@linutronix.de \
--cc=tkhai@yandex.ru \
--cc=torvalds@linux-foundation.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
Powered by JetHome