Hello Thiago,
On Fri, Feb 22, 2019 at 07:57:52PM -0300, Thiago Jung Bauermann wrote:
> When testing DLPAR CPU add/remove on a system under stress,
> pseries_cpu_die() doesn't wait long enough for a CPU to die:
>
> [ 446.983944] cpu 148 (hwid 148) Ready to die...
> [ 446.984062] cpu 149 (hwid 14
Hello Michael,
On Mon, Jan 14, 2019 at 12:11:44PM -0600, Michael Bringmann wrote:
> On 1/9/19 12:08 AM, Gautham R Shenoy wrote:
>
> > I did some testing during the holidays. Here are the observations:
> >
> > 1) With just your patch (without any additional debug patch
Hello Thiago,
Wish you a happy 2019!
On Sat, Dec 08, 2018 at 12:40:52AM -0200, Thiago Jung Bauermann wrote:
>
> Gautham R Shenoy writes:
> > On Fri, Dec 07, 2018 at 04:13:11PM +0530, Gautham R Shenoy wrote:
> >> Sure. I will test the patch and report back.
> >
>
On Fri, Dec 07, 2018 at 04:13:11PM +0530, Gautham R Shenoy wrote:
> Hi Thiago,
>
>
> Sure. I will test the patch and report back.
I added the following debug patch on top of your patch, and after an
hour's run, the system crashed. Appending the log at the end.
I suppose
Hi Thiago,
On Thu, Dec 06, 2018 at 03:28:17PM -0200, Thiago Jung Bauermann wrote:
[..snip..]
>
>
> I posted a similar patch last year, but I wasn't able to arrive at a
> root cause analysis like you did:
>
>
https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-February/153734.html
Ah! Nice.
From: "Gautham R. Shenoy"
Hi,
This is the tenth iteration of the patchset to add support for
big-core on POWER9. This patch also optimizes the task placement on
such big-core systems.
The previous versions can be found here:
v9: https://lkml.org/lkml/2018/10/1/608
v8: https://lkm
From: "Gautham R. Shenoy"
POWER9 SMT8 cores consist of two groups of threads, where threads in
each group shares L1-cache. The scheduler is not aware of this
distinction as the current sched-domain hierarchy has all the threads
of the core defined at the SMT domain.
SM
From: "Gautham R. Shenoy"
Currently on POWER9 SMT8 cores systems, in sysfs, we report the
shared_cache_map for L1 caches (both data and instruction) to be the
cpu-ids of the threads in SMT8 cores. This is incorrect since on
POWER9 SMT8 cores there are two groups of threads, each of wh
From: "Gautham R. Shenoy"
On IBM POWER9, the device tree exposes a property array identifed by
"ibm,thread-groups" which will indicate which groups of threads share
a particular set of resources.
As of today we only have one form of grouping identifying the group of
thre
Hello Mikey,
On Wed, Jul 18, 2018 at 09:24:19AM +1000, Michael Neuling wrote:
>
> > DEFINE(PPC_DBELL_SERVER, PPC_DBELL_SERVER);
> > diff --git a/arch/powerpc/kernel/idle_book3s.S
> > b/arch/powerpc/kernel/idle_book3s.S
> > index d85d551..5069d42 100644
> > --- a/arch/powerpc/kernel/idle_book3
On Tue, Jul 03, 2018 at 07:36:16PM +0530, Vaidyanathan Srinivasan wrote:
> * Gautham R Shenoy [2018-07-03 10:54:16]:
>
> > From: "Gautham R. Shenoy"
> >
> > In the situations where snooze is the only cpuidle state due to
> > firmware not exposing any
From: "Gautham R. Shenoy"
In the situations where snooze is the only cpuidle state due to
firmware not exposing any platform idle states, the idle CPUs will
remain in snooze for a long time with interrupts disabled causing the
Hard-lockup detector to complain.
watchdog: CPU 51 det
Hello Michael,
On Fri, May 18, 2018 at 11:21:22PM +1000, Michael Ellerman wrote:
> "Gautham R. Shenoy" writes:
>
> > diff --git a/arch/powerpc/kernel/setup-common.c
> > b/arch/powerpc/kernel/setup-common.c
> > index 0af5c11..884dff2 100644
> > --- a/arch
Hello Michael,
On Fri, May 18, 2018 at 11:14:04PM +1000, Michael Ellerman wrote:
> Gautham R Shenoy writes:
> ...
> >> > @@ -565,7 +615,16 @@ void __init smp_setup_cpu_maps(void)
> >> > vdso_data->processorCount = num_present_cpus(
On Mon, May 14, 2018 at 01:22:07PM +1000, Michael Neuling wrote:
> On Fri, 2018-05-11 at 16:47 +0530, Gautham R. Shenoy wrote:
> > From: "Gautham R. Shenoy"
> >
> > Each of the SMT4 cores forming a fused-core are more or less
> > independent units. Thus whe
Hi Mikey,
On Mon, May 14, 2018 at 01:21:11PM +1000, Michael Neuling wrote:
> Thanks for posting this... A couple of comments below.
Thanks for the review. Replies below.
> > +/*
> > + * check_for_interleaved_big_core - Checks if the core represented by
> > + * dn is a big-core whose threads are
From: "Gautham R. Shenoy"
Each of the SMT4 cores forming a fused-core are more or less
independent units. Thus when multiple tasks are scheduled to run on
the fused core, we get the best performance when the tasks are spread
across the pair of SMT4 cores.
Since the threads in the pa
From: "Gautham R. Shenoy"
Hi,
A pair of IBM POWER9 SMT4 cores can be fused together to form a
big-core with 8 SMT threads. This can be discovered via the
"ibm,thread-groups" CPU property in the device tree which will
indicate which group of threads that share the L1 cache, t
From: "Gautham R. Shenoy"
A pair of IBM POWER9 SMT4 cores can be fused together to form a
big-core with 8 SMT threads. This can be discovered via the
"ibm,thread-groups" CPU property in the device tree which will
indicate which group of threads that share the L1 cache, t
Hi Rafael,
On Wed, Jan 03, 2018 at 11:47:58PM +1100, Balbir Singh wrote:
> On Wed, Jan 3, 2018 at 11:07 PM, Rafael J. Wysocki wrote:
> > On Monday, December 18, 2017 9:38:20 AM CET Gautham R Shenoy wrote:
> >> Hi Balbir,
> >>
> >> On Sun, Dec 17, 2017 at
On Tue, Dec 19, 2017 at 09:21:52PM +1100, Balbir Singh wrote:
> On Tue, Dec 19, 2017 at 8:20 PM, Gautham R Shenoy
> wrote:
> > Hi Viresh,
> > On Mon, Dec 18, 2017 at 01:59:35PM +0530, Viresh Kumar wrote:
> >> On 18-12-17, 10:41, Abhishek wrote:
> >> > We n
Hi Viresh,
On Mon, Dec 18, 2017 at 01:59:35PM +0530, Viresh Kumar wrote:
> On 18-12-17, 10:41, Abhishek wrote:
> > We need to do it in this way as the current implementation takes the max of
> > the PMSR of the cores. Thus, when the frequency is required to be ramped up,
> > it suffices to write to
Hi Balbir,
On Sun, Dec 17, 2017 at 02:04:03PM +1100, Balbir Singh wrote:
> On Wed, Dec 13, 2017 at 5:57 PM, Gautham R. Shenoy
> wrote:
> > From: "Gautham R. Shenoy"
> >
> > On POWERNV platform, the fields for pstates in the Power Management
> > Status
Hi Balbir,
On Sun, Dec 17, 2017 at 02:17:02PM +1100, Balbir Singh wrote:
> On Wed, Dec 13, 2017 at 5:57 PM, Gautham R. Shenoy
[..snip..]
> >
> > -static inline int extract_pstate(u64 pmsr_val, unsigned int shift)
> > +static inline u8 extract_pstate(u64 pmsr_va
Hi Balbir,
On Sun, Dec 17, 2017 at 02:15:25PM +1100, Balbir Singh wrote:
> On Wed, Dec 13, 2017 at 5:57 PM, Gautham R. Shenoy
> wrote:
> > From: "Gautham R. Shenoy"
> >
> > The code in powernv-cpufreq, makes the following two assumptions which
> > are no
From: "Gautham R. Shenoy"
This is a third version of the patch to fix pstate related issues in
the powernv-cpufreq driver.
The previous versions can be found here:
[v2]: https://lkml.org/lkml/2017/12/7/1562
[v1]: https://lkml.org/lkml/2017/11/29/1338
On POWERNV platform, Pst
From: "Gautham R. Shenoy"
The code in powernv-cpufreq, makes the following two assumptions which
are not guaranteed by the device-tree bindings:
1) Pstate ids are continguous: This is used in pstate_to_idx() to
obtain the reverse map from a pstate to it's correspondi
From: "Gautham R. Shenoy"
On POWERNV platform, the fields for pstates in the Power Management
Status Register (PMSR) and the Power Management Control Register
(PMCR) are 8-bits wide. On POWER8 the pstates are negatively numbered
while on POWER9 they are positively numbered.
The d
From: "Gautham R. Shenoy"
On POWER8 and POWER9, the PMSR and the PMCR registers define pstates
to be 8-bit wide values. The device-tree exports pstates as 32-bit
wide values of which the lower byte is the actual pstate.
The current implementation in the kernel treats pstates as in
Hi Balbir,
On Fri, Dec 08, 2017 at 02:44:40PM +1100, Balbir Singh wrote:
> On Thu, Dec 7, 2017 at 4:59 PM, Gautham R. Shenoy
> wrote:
> > From: "Gautham R. Shenoy"
> >
> > On POWERNV platform, Pstates are 8-bit values. On POWER8 they are
> > nega
From: "Gautham R. Shenoy"
On POWERNV platform, Pstates are 8-bit values. On POWER8 they are
negatively numbered while on POWER9 they are positively
numbered. Thus, on POWER9, the maximum number of pstates could be as
high as 256.
The current code interprets pstates as a signed 8-bit v
Hi Michael,
On Wed, Dec 06, 2017 at 09:54:27PM +1100, Michael Ellerman wrote:
> Shilpasri G Bhat writes:
>
> > From: "Gautham R. Shenoy"
> >
> > Pstates are 8bit values but on POWER8 they are negative and on POWER9
> > they are positive. This patch adds
On Wed, Sep 20, 2017 at 04:27:27PM -0700, Kees Cook wrote:
> Remove uses of init_timer_pinned_deferrable() with open-coded
> function and data assignments that could be expressed using
> setup_pinned_deferrable_timer().
>
> Signed-off-by: Kees Cook
Reviewed-by: Ga
On Fri, Sep 22, 2017 at 04:32:18PM +0530, Abhishek Goel wrote:
> cpuidle_monitor used to assume that cpu0 is always online.
On what platform is this assumption not valid and what is the problem
caused due to this.
> Now the
> cpuidle_monitor function searches for the first online cpu and use
> it
From: "Gautham R. Shenoy"
commit 24be85a23d1f ("powerpc/powernv: Clear PECE1 in LPCR via
stop-api only on Hotplug") clears the PECE1 bit of the LPCR via
stop-api during CPU-Hotplug to prevent wakeup due to a decrementer on
an offlined CPU which is in a deep stop state.
I
From: "Gautham R. Shenoy"
Currently, we use the opal call opal_slw_set_reg() to inform the
Sleep-Winkle Engine (SLW) to restore the contents of some of the
Hypervisor state on wakeup from deep idle states that lose full
hypervisor context (characterized by the flag
OPAL_PM_LOSE_FU
On Mon, Aug 07, 2017 at 06:26:44PM +1000, Michael Ellerman wrote:
> Gautham R Shenoy writes:
> > On Tue, Aug 01, 2017 at 08:56:18PM +1000, Michael Ellerman wrote:
> >> "Gautham R. Shenoy" writes:
> >> >
> >> > Subject: [v3 PATCH 1
From: "Gautham R. Shenoy"
The stop4 idle state on POWER9 is a deep idle state which loses
hypervisor resources, but whose latency is low enough that it can be
exposed via cpuidle.
Until now, the deep idle states which lose hypervisor resources (eg:
winkle) were only exposed via C
From: "Gautham R. Shenoy"
Hi,
This is the fourth iteration of the patchset to enable exploitation of
stop4 idle state on POWER9 via cpuidle.
The earlier version can be found here :
[v3]: https://lkml.org/lkml/2017/7/21/209
[v2]: https://lkml.org/lkml/2017/7/19/152
[v1]: https://lkm
From: "Gautham R. Shenoy"
Currently we use the stop-api provided by the firmware to program the
SLW engine to restore the values of hypervisor resources that get lost
on deeper idle states (such as winkle). Since the deep states were
only used for CPU-Hotplug on POWER8 systems, we wou
Hi Michael,
On Tue, Aug 01, 2017 at 08:56:18PM +1000, Michael Ellerman wrote:
> "Gautham R. Shenoy" writes:
> >
> > Subject: [v3 PATCH 1/2] powernv/powerpc:Save/Restore additional SPRs for
> > stop4 cpuidle
>
> I know it's not a big deal, but can we a
On Fri, Aug 04, 2017 at 12:34:22PM +0530, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy"
>
> Currently, we use the opal call opal_slw_set_reg() to inform the
> Sleep-Winkle Engine (SLW) to restore the contents of some of the
> Hypervisor state on wakeup from deep i
On Mon, Jul 31, 2017 at 02:50:22PM +0530, Seeteena Thoufeek wrote:
> The names of the idle states in the output of cpupower monitor
> command are truncated to 4 characters. Hence, On POWER9, since
> the states are named "stop0, stop1, stop2, stop4, stop11",
> this output is ambiguous
>
> root:~# c
From: "Gautham R. Shenoy"
Currently, we use the opal call opal_slw_set_reg() to inform the
Sleep-Winkle Engine (SLW) to restore the contents of some of the
Hypervisor state on wakeup from deep idle states that lose full
hypervisor context (characterized by the flag
OPAL_PM_LOSE_FU
--git a/tools/power/cpupower/utils/idle_monitor/cpupower-monitor.h
> b/tools/power/cpupower/utils/idle_monitor/cpupower-monitor.h
> index 9e43f33..c9179c6 100644
> --- a/tools/power/cpupower/utils/idle_monitor/cpupower-monitor.h
> +++ b/tools/power/cpupower/utils/idle_monitor/cpupower-monitor.h
> @@ -15,7 +15,7 @@
>
> #define MONITORS_MAX 20
> #define MONITOR_NAME_LEN 20
> -#define CSTATE_NAME_LEN 5
> +#define CSTATE_NAME_LEN 16
So, this is based on the CPUIDLE_NAME_LEN I suppose. You might want to
add a comment
about it here.
> #define CSTATE_DESC_LEN 60
>
> int cpu_count;
> --
> 1.8.3.1
>
Otherwise the patch looks good.
Reviewed-by: Gautham R. Shenoy
--
Thanks and Regards
gautham.
From: "Gautham R. Shenoy"
Currently we use the stop-api provided by the firmware to program the
SLW engine to restore the values of hypervisor resources that get lost
on deeper idle states (such as winkle). Since the deep states were
only used for CPU-Hotplug on POWER8 systems, we wou
From: "Gautham R. Shenoy"
The stop4 idle state on POWER9 is a deep idle state which loses
hypervisor resources, but whose latency is low enough that it can be
exposed via cpuidle.
Until now, the deep idle states which lose hypervisor resources (eg:
winkle) were only exposed via C
From: "Gautham R. Shenoy"
Hi,
This is the third iteration of the patchset to enable exploitation of
stop4 idle state on POWER9 via cpuidle.
The earlier version can be found here :
[v2]: https://lkml.org/lkml/2017/7/19/152
[v1]: https://lkml.org/lkml/2017/7/18/691
The changes
Hi Nicholas, Michael,
On Wed, Jul 19, 2017 at 10:07:05PM +1000, Michael Ellerman wrote:
> Nicholas Piggin writes:
> >> diff --git a/arch/powerpc/kernel/asm-offsets.c
> >> b/arch/powerpc/kernel/asm-offsets.c
> >> index a7b5af3..0262283 100644
> >> --- a/arch/powerpc/kernel/asm-offsets.c
> >> +++
From: "Gautham R. Shenoy"
The stop4 idle state on POWER9 is a deep idle state which loses
hypervisor resources, but whose latency is low enough that it can be
exposed via cpuidle.
Until now, the deep idle states which lose hypervisor resources (eg:
winkle) were only exposed via C
From: "Gautham R. Shenoy"
Currently we use the stop-api provided by the firmware to program the
SLW engine to restore the values of hypervisor resources that get lost
on deeper idle states (such as winkle). Since the deep states were
only used for CPU-Hotplug on POWER8 systems, we wou
From: "Gautham R. Shenoy"
Hi,
This is the second iteration of the patchset to enable exploitation of
stop4 idle state on POWER9 via cpuidle.
The earlier version can be found here :
https://lkml.org/lkml/2017/7/18/691
The change from the first version is to the second patch titled
Hello Nicholas,
On Wed, Jul 19, 2017 at 12:14:12PM +1000, Nicholas Piggin wrote:
> Thanks for working on these patches. We really need to get this stuff
> merged and tested asap :)
>
> On Tue, 18 Jul 2017 19:58:49 +0530
[..snip..]
> > diff --git a/arch/powerpc/platforms/powernv/smp.c
> > b/arc
From: "Gautham R. Shenoy"
Currently we use the stop-api provided by the firmware to program the
SLW engine to restore the values of hypervisor resources that get lost
on deeper idle states (such as winkle). Since the deep states were
only used for CPU-Hotplug on POWER8 systems, we wou
From: "Gautham R. Shenoy"
The stop4 idle state on POWER9 is a deep idle state which loses
hypervisor resources, but whose latency is low enough that it can be
exposed via cpuidle.
Until now, the deep idle states which lose hypervisor resources (eg:
winkle) were only exposed via C
From: "Gautham R. Shenoy"
Hi,
The stop4 idle state on POWER9 is a deep idle state which loses
hypervisor resources, but whose latency is low enough that it can be
exposed via cpuidle.
Until now, the deep idle states which lose hypervisor resources (eg:
winkle) were only exposed via C
On Sat, Jul 08, 2017 at 07:05:26PM +1000, Nicholas Piggin wrote:
> On Fri, 7 Jul 2017 23:07:10 +0530
> Gautham R Shenoy wrote:
>
> > On Fri, Jul 07, 2017 at 01:29:16AM +1000, Nicholas Piggin wrote:
> > > On Wed, 5 Jul 2017 22:08:16 +0530
> > > "Gautham R.
On Fri, Jul 07, 2017 at 01:29:16AM +1000, Nicholas Piggin wrote:
> On Wed, 5 Jul 2017 22:08:16 +0530
> "Gautham R. Shenoy" wrote:
>
> > From: "Gautham R. Shenoy"
> >
> > Currently, we use the opal call opal_slw_set_reg() to inform the that
&
On Fri, Jul 07, 2017 at 01:16:09AM +1000, Nicholas Piggin wrote:
> On Wed, 5 Jul 2017 22:08:15 +0530
> "Gautham R. Shenoy" wrote:
>
> > From: "Gautham R. Shenoy"
> >
> > On POWER9 DD1, in order to get around a hardware issue, we store in
>
Hi Nicholas,
On Fri, Jul 07, 2017 at 01:06:46AM +1000, Nicholas Piggin wrote:
> On Wed, 5 Jul 2017 22:08:14 +0530
> "Gautham R. Shenoy" wrote:
>
> > From: "Gautham R. Shenoy"
> >
> > In this patch we define a new function named pnv_power8_idle_i
Hello Nicholas,
On Fri, Jul 07, 2017 at 01:01:49AM +1000, Nicholas Piggin wrote:
> On Wed, 5 Jul 2017 22:08:13 +0530
> "Gautham R. Shenoy" wrote:
>
> > From: "Gautham R. Shenoy"
> >
> > In the current idle initialization code, if there are
Hello Nicholas,
On Fri, Jul 07, 2017 at 12:53:40AM +1000, Nicholas Piggin wrote:
> On Wed, 5 Jul 2017 22:08:12 +0530
> "Gautham R. Shenoy" wrote:
>
> > From: "Gautham R. Shenoy"
> >
> > The details of the platform idle state are exposed by
From: "Gautham R. Shenoy"
The details of the platform idle state are exposed by the firmware to
the kernel via device tree.
In the current code, we parse the device tree twice :
1) During the boot up in arch/powerpc/platforms/powernv/idle.c Here,
the device tree is parsed to obtain t
From: "Gautham R. Shenoy"
In this patch we define a new function named pnv_power8_idle_init().
We move the following code from pnv_init_idle_states() into this newly
defined function.
a) That patches out pnv_fastsleep_workaround_at_entry/exit when
no s
From: "Gautham R. Shenoy"
Hi,
This patch set aims at cleaning up the powernv idle initialization
code mainly covering the following
a) Currently there is redundant code for parsing the device-tree for
idle states. We do it in two places, once during the platform idle
initializa
From: "Gautham R. Shenoy"
In the current idle initialization code, if there are failures in
pnv_probe_idle_states, then no platform idle state is
enabled. However, since the error is not propagated to the top-level
function pnv_init_idle_states, we continue initialization in this
From: "Gautham R. Shenoy"
Currently, we use the opal call opal_slw_set_reg() to inform the that
the Sleep-Winkle Engine (SLW) to restore the contents of some of the
Hypervisor state on wakeup from deep idle states that lose full
hypervisor context (characterized b
From: "Gautham R. Shenoy"
On POWER9 DD1, in order to get around a hardware issue, we store in
every CPU thread's paca the paca pointers of all its siblings.
Move this code into pnv_alloc_idle_core_states() soon after the space
for saving the sibling pacas is allocated.
Signed-of
On Tue, May 30, 2017 at 09:10:06PM +1000, Nicholas Piggin wrote:
> On Tue, 30 May 2017 16:20:55 +0530
> Gautham R Shenoy wrote:
>
> > On Tue, May 30, 2017 at 05:13:57PM +1000, Nicholas Piggin wrote:
> > > On Tue, 16 May 2017 14:19:48 +0530
> > > "Gautham R.
On Tue, May 30, 2017 at 05:13:57PM +1000, Nicholas Piggin wrote:
> On Tue, 16 May 2017 14:19:48 +0530
> "Gautham R. Shenoy" wrote:
>
> > From: "Gautham R. Shenoy"
> >
> > The current code in the cpuidle-powernv intialization only allows deep
>
On Tue, May 30, 2017 at 04:17:31PM +1000, Nicholas Piggin wrote:
> On Tue, 16 May 2017 14:19:45 +0530
> "Gautham R. Shenoy" wrote:
>
> > From: "Gautham R. Shenoy"
> >
> > On wakeup from a deep stop state which is supposed to lose the
> > h
On Tue, May 30, 2017 at 04:12:38PM +1000, Nicholas Piggin wrote:
> On Tue, 16 May 2017 14:19:44 +0530
> "Gautham R. Shenoy" wrote:
>
> > From: "Gautham R. Shenoy"
> >
> > On POWER8, in case of
> >- nap: both timebase and hypervisor stat
Hi Nicholas,
On Tue, May 30, 2017 at 03:56:12PM +1000, Nicholas Piggin wrote:
> On Tue, 16 May 2017 14:19:43 +0530
> "Gautham R. Shenoy" wrote:
>
> > From: "Gautham R. Shenoy"
> >
> > The lower 8 bits of core_idle_state_ptr tracks the numb
From: "Gautham R. Shenoy"
The current code in the cpuidle-powernv intialization only allows deep
stop states (indicated by OPAL_PM_STOP_INST_DEEP) which lose timebase
(indicated by OPAL_PM_TIMEBASE_STOP). This assumption goes back to
POWER8 time where deep states used to lose th
kshay Adiga
Signed-off-by: Gautham R. Shenoy
---
arch/powerpc/platforms/powernv/idle.c | 83 ++-
1 file changed, 52 insertions(+), 31 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/idle.c
b/arch/powerpc/platforms/powernv/idle.c
index 84eb9bc..4deac0d 1
From: "Gautham R. Shenoy"
Hi,
This patch series contains some of the fixes required for enabling
support for deep stop states such as STOP4 and STOP11 via CPU-Hotplug.
These fixes mainly ensure that some of the hypervisor resources which
are lost during the deep stop state are
From: "Gautham R. Shenoy"
On POWER8, in case of
- nap: both timebase and hypervisor state is retained.
- fast-sleep: timebase is lost. But the hypervisor state is retained.
- winkle: timebase and hypervisor state is lost.
Hence, the current code for handling exit from a
From: "Gautham R. Shenoy"
The lower 8 bits of core_idle_state_ptr tracks the number of non-idle
threads in the core. This is supposed to be initialized to bit-map
corresponding to the threads_per_core. However, currently it is
initialized to PNV_CORE_IDLE_THREAD_BITS (0xFF). This is c
From: "Gautham R. Shenoy"
On Power9 DD1 due to a hardware bug the Power-Saving Level Status
field (PLS) of the PSSCR for a thread waking up from a deep state can
under-report if some other thread in the core is in a shallow stop
state. The scenario in which this can manifest is
From: "Gautham R. Shenoy"
On wakeup from a deep stop state which is supposed to lose the
hypervisor state, we don't restore the LPCR to the old value but set
it to a "sane" value via cur_cpu_spec->cpu_restore().
The problem is that the "sane" value doesn&#x
From: "Gautham R. Shenoy"
commit 17ed4c8f81da ("powerpc/powernv: Recover correct PACA on wakeup
from a stop on P9 DD1") promises to set the NAPSTATELOST bit in paca
after recovering the correct paca for the thread waking up from stop1
on DD1, so that the GPRs can be corre
On Thu, Apr 13, 2017 at 05:18:17PM +1000, Nicholas Piggin wrote:
> On Thu, 13 Apr 2017 16:27:34 +1000
> Michael Neuling wrote:
>
> > On Thu, 2017-04-13 at 14:12 +1000, Benjamin Herrenschmidt wrote:
> > > On Thu, 2017-04-13 at 09:28 +0530, Aneesh Kumar K.V wrote:
> > > > > #endif
> > > > >
On Thu, Apr 13, 2017 at 04:55:45PM +1000, Michael Neuling wrote:
> On Wed, 2017-04-12 at 17:16 +0530, Gautham R. Shenoy wrote:
> > From: "Gautham R. Shenoy"
> >
> > The idle-exit code assumes that if Timebase is not lost, then neither
> > are the per-core hy
On Thu, Apr 13, 2017 at 08:00:47PM +1000, Michael Ellerman wrote:
> Michael Neuling writes:
>
> > On Wed, 2017-04-12 at 17:16 +0530, Gautham R. Shenoy wrote:
> >> From: "Gautham R. Shenoy"
> >>
> >> This patch ensures that POWER8 an
From: "Gautham R. Shenoy"
Hi,
This patchset contains three fixes required to get a deep stop state
that can lose the Hypervisor state to work correctly.
The first patch in the series uses the correct value for the
IDLE_THREAD_BITS on POWER8 which has 8 threads per core and on POWER9
From: "Gautham R. Shenoy"
The idle-exit code assumes that if Timebase is not lost, then neither
are the per-core hypervisor resources lost. This was true on POWER8
where fast-sleep lost only TB but not per-core resources, and winkle
lost both.
This assumption is not true for POWE
From: "Gautham R. Shenoy"
On wakeup from a deep-stop used for CPU-Hotplug, we invoke
cur_cpu_spec->cpu_restore() which would set sane default values to
various SPRs including LPCR.
On POWER9, the cpu_restore_power9() call would would restore LPCR to a
sane value that is set at ea
From: "Gautham R. Shenoy"
This patch ensures that POWER8 and POWER9 processors use the correct
value of IDLE_THREAD_BITS as POWER8 has 8 threads per core and hence
the IDLE_THREAD_BITS should be 0xFF while POWER9 has only 4 threads
per core and hence the IDLE_THREAD_BITS should be 0x
On Mon, Mar 27, 2017 at 10:43:44PM +1100, Michael Ellerman wrote:
> "Gautham R. Shenoy" writes:
>
> > diff --git a/arch/powerpc/platforms/powernv/idle.c
> > b/arch/powerpc/platforms/powernv/idle.c
> > index 419edff..f335e0f 100644
> > --- a/arch/powerpc
5c/0x78
>
> This patch fixes the bug by passing correct cpumask from
> powernv-cpuidle driver.
>
> Signed-off-by: Vaidyanathan Srinivasan
Reviewed-by: Gautham R. Shenoy
> ---
> drivers/cpuidle/cpuidle-powernv.c | 18 ++
> 1 file changed, 18 insertion
ous ldbar value is written back to the LDBAR for that
> cpu.
>
> To register the hotplug functions for thread_imc, a new state
> CPUHP_AP_PERF_POWERPC_THREADIMC_ONLINE is added to the list of existing
> states.
>
> Cc: Gautham R. Shenoy
> Cc: Balbir Singh
> Cc: Benja
Hi Maddy, Hemant, Anju,
On Thu, Mar 16, 2017 at 01:05:02PM +0530, Madhavan Srinivasan wrote:
[..snip..]
> +
> +static void core_imc_change_cpu_context(int old_cpu, int new_cpu)
> +{
> + if (!core_imc_pmu)
> + return;
> + perf_pmu_migrate_context(&core_imc_pmu->pmu, old_cpu, n
plug, dying CPU is checked to see whether it is one of the
> designated cpus, if yes, next online cpu from the same chip (for nest
> units) is designated as new cpu to read counters. For this purpose, we
> introduce a new state : CPUHP_AP_PERF_POWERPC_NEST_ONLINE.
>
> Cc: Gautham R.
From: "Gautham R. Shenoy"
Currently during idle-init on power9, if we don't find suitable stop
states in the device tree that can be used as the
default_stop/deepest_stop, we set stop0 (ESL=1,EC=1) as the default
stop state psscr to be used by power9_idle and deepest stop state
w
From: "Gautham R. Shenoy"
Move the piece of code in powernv/smp.c::pnv_smp_cpu_kill_self() which
transitions the CPU to the deepest available platform idle state to a
new function named pnv_cpu_offline() in powernv/idle.c. The rationale
behind this code movement is that the data r
From: "Gautham R. Shenoy"
Hi,
This is the third version of the patchset containing the fixes to
make CPU-Hotplug working on correctly on POWER9 DD1 systems.
The earlier versions can be found here:
[v2] : https://lkml.org/lkml/2017/3/20/555
[v1] : https://lkml.org/lkml/2017/3/13/46
From: "Gautham R. Shenoy"
Currently, the powernv cpu-offline function assumes that platform idle
states such as stop on POWER9, winkle/sleep/nap on POWER8 are always
available. On POWER8, it picks nap as the default state if other deep
idle states like sleep/winkle are not available a
From: "Gautham R. Shenoy"
POWER9 DD1.0 hardware has an issue due to which the SPRs of a thread
waking up from stop 0,1,2 with ESL=1 can endup being misplaced in the
core. Thus the HSPRG0 of a thread waking up from can contain the paca
pointer of its sibling.
This patch implements
On Tue, Mar 21, 2017 at 02:59:46AM +1000, Nicholas Piggin wrote:
> On Mon, 20 Mar 2017 21:24:18 +0530
> "Gautham R. Shenoy" wrote:
>
> > From: "Gautham R. Shenoy"
> >
> > POWER9 DD1.0 hardware has an issue due to which the SPRs of a thread
>
Hi,
On Tue, Mar 21, 2017 at 02:39:34AM +1000, Nicholas Piggin wrote:
> > @@ -241,8 +240,9 @@ static DEVICE_ATTR(fastsleep_workaround_applyonce, 0600,
> > * The default stop state that will be used by ppc_md.power_save
> > * function on platforms that support stop instruction.
> > */
> > -u64
101 - 200 of 525 matches
Mail list logo
