[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <315b0b80f7f541b99a49a9fecb743874f31d95ba.camel@kernel.org>
Date: Mon, 30 May 2022 20:02:57 +0200
From: nicolas saenz julienne <nsaenz@...nel.org>
To: Frederic Weisbecker <frederic@...nel.org>,
LKML <linux-kernel@...r.kernel.org>
Cc: Peter Zijlstra <peterz@...radead.org>,
Phil Auld <pauld@...hat.com>,
Alex Belits <abelits@...vell.com>,
Xiongfeng Wang <wangxiongfeng2@...wei.com>,
Neeraj Upadhyay <quic_neeraju@...cinc.com>,
Thomas Gleixner <tglx@...utronix.de>,
Yu Liao <liaoyu15@...wei.com>,
Boqun Feng <boqun.feng@...il.com>,
"Paul E . McKenney" <paulmck@...nel.org>,
Marcelo Tosatti <mtosatti@...hat.com>,
Paul Gortmaker <paul.gortmaker@...driver.com>,
Uladzislau Rezki <uladzislau.rezki@...y.com>,
Joel Fernandes <joel@...lfernandes.org>,
Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH 20/21] rcu/context_tracking: Merge dynticks counter and
context tracking states
Hi Frederic,
On Thu, 2022-05-19 at 16:58 +0200, Frederic Weisbecker wrote:
> Updating the context tracking state and the RCU dynticks counter
> atomically in a single operation is a first step towards improving CPU
> isolation. This makes the context tracking state updates fully ordered
> and therefore allow for later enhancements such as postponing some work
> while a task is running isolated in userspace until it ever comes back
> to the kernel.
>
> The state field becomes divided in two parts:
>
> 1) Two Lower bits for context tracking state:
>
> CONTEXT_KERNEL = 0
> CONTEXT_IDLE = 1,
> CONTEXT_USER = 2,
> CONTEXT_GUEST = 3,
>
> 2) Higher bits for RCU eqs dynticks counting:
>
> RCU_DYNTICKS_IDX = 4
>
> The dynticks counting is always incremented by this value.
> (state & RCU_DYNTICKS_IDX) means we are NOT in an extended quiescent
> state. This makes the chance for a collision more likely between two
> RCU dynticks snapshots but wrapping up 28 bits of eqs dynticks
> increments still takes some bad luck (also rdp.dynticks_snap could be
> converted from int to long?)
>
> Some RCU eqs functions have been renamed to better reflect their broader
> scope that now include context tracking state.
>
> Signed-off-by: Frederic Weisbecker <frederic@...nel.org>
> Cc: Paul E. McKenney <paulmck@...nel.org>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Neeraj Upadhyay <quic_neeraju@...cinc.com>
> Cc: Uladzislau Rezki <uladzislau.rezki@...y.com>
> Cc: Joel Fernandes <joel@...lfernandes.org>
> Cc: Boqun Feng <boqun.feng@...il.com>
> Cc: Nicolas Saenz Julienne <nsaenz@...nel.org>
> Cc: Marcelo Tosatti <mtosatti@...hat.com>
> Cc: Xiongfeng Wang <wangxiongfeng2@...wei.com>
> Cc: Yu Liao<liaoyu15@...wei.com>
> Cc: Phil Auld <pauld@...hat.com>
> Cc: Paul Gortmaker<paul.gortmaker@...driver.com>
> Cc: Alex Belits <abelits@...vell.com>
> ---
While working on a feature on top of this series (IPI deferral stuff) I believe
I've found a discrepancy on how context state is being updated:
- When servicing an IRQ from user-space, we increment dynticks, and clear the
ct state to show we're in-kernel.
- When servicing an IRQ from idle/guest or an NMI from any context we only
increment the dynticks counter. The ct state remains unchanged.
Regards,
Nicolas
Powered by blists - more mailing lists