On Mon, 19 Sept 2022 at 12:18, Peter Zijlstra wrote:
>
> Hi All!
>
> At long last, a respin of the cpuidle vs rcu cleanup patches.
>
> v1: https://lkml.kernel.org/r/20220608142723.103523...@infradead.org
>
> These here patches clean up the mess that is cpuidle vs rcuidle.
>
> At the end of the rid
Hi,
* Peter Zijlstra [220919 10:08]:
> Hi All!
>
> At long last, a respin of the cpuidle vs rcu cleanup patches.
>
> v1: https://lkml.kernel.org/r/20220608142723.103523...@infradead.org
>
> These here patches clean up the mess that is cpuidle vs rcuidle.
I just gave these a quick test and thi
Because Nadav asked about tracing/kprobing idle, I had another go around
and noticed not all functions calling ct_cpuidle_enter are __cpuidle.
Basically all cpuidle_driver::enter functions should be __cpuidle; i'll
do that audit shortly.
For now this is ct_cpuidle_enter / CPU_IDLE_ENTER users.
On Mon, Sep 19, 2022 at 11:59:39AM +0200, Peter Zijlstra wrote:
> Hi All!
>
> At long last, a respin of the cpuidle vs rcu cleanup patches.
>
> v1: https://lkml.kernel.org/r/20220608142723.103523...@infradead.org
>
> These here patches clean up the mess that is cpuidle vs rcuidle.
>
> At the en
On Mon, Sep 19, 2022 at 12:17 PM Peter Zijlstra wrote:
>
> Hi All!
>
> At long last, a respin of the cpuidle vs rcu cleanup patches.
>
> v1: https://lkml.kernel.org/r/20220608142723.103523...@infradead.org
>
> These here patches clean up the mess that is cpuidle vs rcuidle.
>
> At the end of the r
Hi All!
At long last, a respin of the cpuidle vs rcu cleanup patches.
v1: https://lkml.kernel.org/r/20220608142723.103523...@infradead.org
These here patches clean up the mess that is cpuidle vs rcuidle.
At the end of the ride there's only on RCU_NONIDLE user left:
arch/arm64/kernel/suspend.
