From: Frederic Weisbecker <frederic@kernel.org>
To: Alex Belits <abelits@marvell.com>
Cc: "rostedt@goodmis.org" <rostedt@goodmis.org>,
Prasun Kapoor <pkapoor@marvell.com>,
"mingo@kernel.org" <mingo@kernel.org>,
"davem@davemloft.net" <davem@davemloft.net>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"will@kernel.org" <will@kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH v4 03/13] task_isolation: userspace hard isolation from kernel
Date: Thu, 1 Oct 2020 16:40:52 +0200 [thread overview]
Message-ID: <20201001144052.GA6595@lothringen> (raw)
In-Reply-To: <b18546567a2ed61073ae86f2d9945257ab285dfa.camel@marvell.com>
On Wed, Jul 22, 2020 at 02:49:49PM +0000, Alex Belits wrote:
> +/**
> + * task_isolation_kernel_enter() - clear low-level task isolation flag
> + *
> + * This should be called immediately after entering kernel.
> + */
> +static inline void task_isolation_kernel_enter(void)
> +{
> + unsigned long flags;
> +
> + /*
> + * This function runs on a CPU that ran isolated task.
> + *
> + * We don't want this CPU running code from the rest of kernel
> + * until other CPUs know that it is no longer isolated.
> + * When CPU is running isolated task until this point anything
> + * that causes an interrupt on this CPU must end up calling this
> + * before touching the rest of kernel. That is, this function or
> + * fast_task_isolation_cpu_cleanup() or stop_isolation() calling
> + * it. If any interrupt, including scheduling timer, arrives, it
> + * will still end up here early after entering kernel.
> + * From this point interrupts are disabled until all CPUs will see
> + * that this CPU is no longer running isolated task.
> + *
> + * See also fast_task_isolation_cpu_cleanup().
> + */
> + smp_rmb();
I'm a bit confused what this read memory barrier is ordering. Also against
what it pairs.
> + if((this_cpu_read(ll_isol_flags) & FLAG_LL_TASK_ISOLATION) == 0)
> + return;
> +
> + local_irq_save(flags);
> +
> + /* Clear low-level flags */
> + this_cpu_write(ll_isol_flags, 0);
> +
> + /*
> + * If something happened that requires a barrier that would
> + * otherwise be called from remote CPUs by CPU kick procedure,
> + * this barrier runs instead of it. After this barrier, CPU
> + * kick procedure would see the updated ll_isol_flags, so it
> + * will run its own IPI to trigger a barrier.
> + */
> + smp_mb();
> + /*
> + * Synchronize instructions -- this CPU was not kicked while
> + * in isolated mode, so it might require synchronization.
> + * There might be an IPI if kick procedure happened and
> + * ll_isol_flags was already updated while it assembled a CPU
> + * mask. However if this did not happen, synchronize everything
> + * here.
> + */
> + instr_sync();
It's the first time I meet an instruction barrier. I should get information
about that but what is it ordering here?
> + local_irq_restore(flags);
> +}
Thanks.
next prev parent reply other threads:[~2020-10-01 14:40 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-22 14:44 [PATCH v4 00/13] "Task_isolation" mode Alex Belits
2020-07-22 14:48 ` [PATCH v4 02/13] task_isolation: vmstat: add vmstat_idle function Alex Belits
2020-07-22 14:49 ` [PATCH v4 03/13] task_isolation: userspace hard isolation from kernel Alex Belits
2020-07-22 14:49 ` Alex Belits
2020-10-01 13:56 ` Frederic Weisbecker
2020-10-04 14:44 ` [EXT] " Alex Belits
2020-10-04 23:14 ` Frederic Weisbecker
2020-10-05 18:52 ` Nitesh Narayan Lal
2020-10-06 10:35 ` Frederic Weisbecker
2020-10-17 1:13 ` Alex Belits
2020-10-17 1:08 ` Alex Belits
2020-10-17 16:08 ` Thomas Gleixner
2020-10-17 16:15 ` Alex Belits
2020-10-17 20:03 ` Thomas Gleixner
2020-10-06 11:01 ` Alex Belits
2020-10-01 14:40 ` Frederic Weisbecker [this message]
2020-10-04 15:01 ` Alex Belits
[not found] ` <04be044c1bcd76b7438b7563edc35383417f12c8.camel-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
2020-07-22 14:47 ` [PATCH v4 01/13] task_isolation: vmstat: add quiet_vmstat_sync function Alex Belits
2020-07-22 14:47 ` Alex Belits
2020-07-22 14:51 ` [PATCH v4 04/13] task_isolation: Add task isolation hooks to arch-independent code Alex Belits
2020-07-22 14:51 ` Alex Belits
2020-07-22 14:55 ` [PATCH 08/13] task_isolation: arch/arm64: enable task isolation functionality Alex Belits
2020-07-22 14:55 ` Alex Belits
2020-07-22 14:56 ` [PATCH v4 09/13] task_isolation: arch/arm: " Alex Belits
2020-07-22 14:56 ` Alex Belits
2020-07-22 14:58 ` [PATCH v4 11/13] task_isolation: net: don't flush backlog on CPUs running isolated tasks Alex Belits
2020-07-22 14:58 ` Alex Belits
2020-10-01 14:47 ` Frederic Weisbecker
2020-10-04 17:12 ` [EXT] " Alex Belits
2021-01-22 14:13 ` Marcelo Tosatti
2021-01-22 16:13 ` Paolo Abeni
2020-07-22 14:59 ` [PATCH 13/13] task_isolation: kick_all_cpus_sync: don't kick isolated cpus Alex Belits
2020-07-22 14:59 ` Alex Belits
2020-07-22 14:51 ` [PATCH v4 05/13] task_isolation: Add xen-specific hook Alex Belits
2020-07-22 14:51 ` Alex Belits
2020-07-22 14:53 ` [PATCH 06/13] task_isolation: Add driver-specific hooks Alex Belits
2020-07-22 14:53 ` Alex Belits
2020-07-22 14:54 ` [PATCH v4 07/13] task_isolation: arch/x86: enable task isolation functionality Alex Belits
2020-07-22 14:54 ` Alex Belits
2020-07-22 14:57 ` [PATCH v4 10/13] task_isolation: don't interrupt CPUs with tick_nohz_full_kick_cpu() Alex Belits
2020-10-01 14:44 ` Frederic Weisbecker
2020-10-04 15:22 ` [EXT] " Alex Belits
2020-10-06 21:41 ` Frederic Weisbecker
2020-10-17 0:17 ` Alex Belits
2020-07-22 14:59 ` [PATCH v4 12/13] task_isolation: ringbuffer: don't interrupt CPUs running isolated tasks on buffer resize Alex Belits
2020-07-22 14:59 ` Alex Belits
2020-07-23 13:17 ` [PATCH v4 00/13] "Task_isolation" mode Thomas Gleixner
2020-07-23 14:26 ` Peter Zijlstra
2020-07-23 14:53 ` Thomas Gleixner
2020-07-23 14:29 ` Peter Zijlstra
2020-07-23 15:41 ` [EXT] " Alex Belits
2020-07-23 15:48 ` Peter Zijlstra
2020-07-23 15:48 ` Peter Zijlstra
2020-07-23 16:19 ` Alex Belits
2020-07-23 16:19 ` Alex Belits
2020-07-23 15:18 ` Alex Belits
[not found] ` <831e023422aa0e4cb3da37ceef6fdcd5bc854682.camel-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
2020-07-23 15:49 ` Peter Zijlstra
2020-07-23 15:49 ` Peter Zijlstra
2020-07-23 16:50 ` Alex Belits
2020-07-23 21:44 ` Thomas Gleixner
2020-07-23 21:44 ` Thomas Gleixner
2020-07-24 3:00 ` [EXT] " Alex Belits
2020-07-24 16:08 ` Thomas Gleixner
2020-07-24 16:08 ` Thomas Gleixner
2020-07-23 21:31 ` Thomas Gleixner
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=20201001144052.GA6595@lothringen \
--to=frederic@kernel.org \
--cc=abelits@marvell.com \
--cc=catalin.marinas@arm.com \
--cc=davem@davemloft.net \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=pkapoor@marvell.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=will@kernel.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;
as well as URLs for NNTP newsgroup(s).