[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210929190935.GX4323@worktop.programming.kicks-ass.net>
Date: Wed, 29 Sep 2021 21:09:35 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: gor@...ux.ibm.com, jpoimboe@...hat.com, jikos@...nel.org,
mbenes@...e.cz, pmladek@...e.com, mingo@...nel.org,
linux-kernel@...r.kernel.org, joe.lawrence@...hat.com,
fweisbec@...il.com, tglx@...utronix.de, hca@...ux.ibm.com,
svens@...ux.ibm.com, sumanthk@...ux.ibm.com,
live-patching@...r.kernel.org, rostedt@...dmis.org, x86@...nel.org
Subject: Re: [RFC][PATCH v2 08/11] context_tracking,rcu: Replace RCU dynticks
counter with context_tracking
On Wed, Sep 29, 2021 at 11:37:01AM -0700, Paul E. McKenney wrote:
> On Wed, Sep 29, 2021 at 05:17:31PM +0200, Peter Zijlstra wrote:
> The CT_SEQ_WORK bit means neither idle nor nohz_full user, correct?
That bit is indeed independent, it can get set remotely by cmpxchg when
in user/eqs state and will be tested and (eventually) cleared when
leaving user/eqs state.
> So let's see if I intuited the decoder ring, where "kernel" means that
> portion of the kernel that is non-noinstr...
>
> CT_SEQ_WORK CT_SEQ_NMI CT_SEQ_USER Description?
> 0 0 0 Idle or non-nohz_full user
> 0 0 1 nohz_full user
> 0 1 0 NMI from 0,0,0
> 0 1 1 NMI from 0,0,1
> 1 0 0 Non-idle kernel
> 1 0 1 Cannot happen?
> 1 1 0 NMI from 1,0,1
> 1 1 1 NMI from cannot happen
>
> And of course if a state cannot happen, Murphy says that you will take
> an NMI in that state.
Urgh, you have the bits the 'wrong' way around :-)
MSB 3210
|-------||||
Where [MSB-3] is the actual sequence number, [21] is the state and [0]
is the work-pending bit.
The table for [21] is like:
USER NMI
0 0 kernel
0 1 kernel took nmi
1 0 user
1 1 user took nmi
So effectively EQS is 10 only, the other 3 states are kernel.
Powered by blists - more mailing lists