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
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
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: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 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
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 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
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 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
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
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"
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
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"
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
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
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 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
> > > > >
Hi Nick,
On Fri, May 12, 2017 at 01:15:20AM +1000, Nicholas Piggin wrote:
> Fixes: a7cd88da97 ("powerpc/powernv: Move CPU-Offline idle state invocation
> from smp.c to idle.c")
> Cc: Gautham R. Shenoy
> Signed-off-by: Nicholas Piggin
> ---
> arch/powerpc/platform
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
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
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"
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
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"
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"
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"
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
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
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
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 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 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.
Hi Nick,
(Added Paul Mackerass to the Cc)
On Mon, Jun 12, 2017 at 09:58:22AM +1000, Nicholas Piggin wrote:
> This simplifies the asm and fixes irq-off tracing over sleep
> instructions.
>
> Also move powersave_nap check for POWER8 into C code, and move
> PSSCR register value calculation for POWER
Hi Nick,
On Mon, Jun 12, 2017 at 09:58:24AM +1000, Nicholas Piggin wrote:
> Before the cpuidle driver is enabled, provide a default idle
> function similarly to POWER7/8.
>
> This should not have much effect, because the cpuidle driver
> for powernv is mandatory, but if that changes we should hav
Hi Nick,
On Mon, Jun 12, 2017 at 09:58:25AM +1000, Nicholas Piggin wrote:
> When the CPU wakes from low power state, it begins at the system reset
> interrupt with the exception that caused the wakeup encoded in SRR1.
>
> Today, powernv idle wakeup ignores the wakeup reason (except a special
> ca
rect msgclr
> Different threads, same core: 315k/s 264k/s345k/s
> Different cores:235k/s 242k/s242k/s
>
> Net speedup is +10% for same core, and +3% for different core.
This is good speedup.
Reviewed-by: Gautham R. Shenoy
better with the return predictor.
>
> Signed-off-by: Nicholas Piggin
Reviewed-by: Gautham R. Shenoy
> ---
> arch/powerpc/kernel/exceptions-64s.S | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/exceptions-64s.S
> b/arch/
On Mon, Jun 12, 2017 at 09:58:30AM +1000, Nicholas Piggin wrote:
> In a busy system, idle wakeups can be expected from IPIs and device
> interrupts.
>
> Signed-off-by: Nicholas Piggin
Reviewed-by: Gautham R. Shenoy
> ---
> arch/powerpc/kernel/idle_book3s.S | 2 +-
&g
ime will not have to send an IPI.
>
> Expand the TIF_POLLING_NRFLAG coverage to as large as possible.
>
> Signed-off-by: Nicholas Piggin
Looks good. Were you able to see this make a difference in any of the
tests ?
Reviewed-by: Gautham R. Shenoy
> ---
> drivers/cpuidle/cpuidle
On Mon, Jun 12, 2017 at 09:58:32AM +1000, Nicholas Piggin wrote:
> Ensure these don't get put into bouncing cachelines.
>
> Signed-off-by: Nicholas Piggin
Reviewed-by: Gautham R. Shenoy
> ---
> drivers/cpuidle/cpuidle-powernv.c | 10 +-
> drivers/cpuidle
On Tue, Jun 13, 2017 at 12:46:02AM +1000, Nicholas Piggin wrote:
> Hi Gautham,
>
> Thanks for the reviews.
>
> On Mon, 12 Jun 2017 14:07:27 +0530
> Gautham R Shenoy wrote:
>
> > Hi Nick,
> >
> > (Added Paul Mackerass to the Cc)
> > On Mon, Jun
Hi Nick,
On Mon, Jun 12, 2017 at 09:58:29AM +1000, Nicholas Piggin wrote:
> Idle code now always runs at the 0xc... effective address whether
> in real or virtual mode. This means rfid can be ditched, along
> with a lot of SRR manipulations.
>
> In the wakeup path, carry SRR1 around in r12. Use m
; would get rounded down to zero micro second and make cpuidle
> framework choose deeper idle state when snooze loop is the
> right choice.
>
> Reported-by: Anton Blanchard
> Signed-off-by: Vaidyanathan Srinivasan
This looks good to me.
Reviewed-by: Gautham R. Shenoy
> ---
>
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
t in it. Is that guaranteed on POWER9? If so
> it is at least deserving of a comment.
How about the following patch
---x8-----x8-----
>From a17e4f71bfc9d208c45335acb47fc2b3a9f61923 Mon Sep 17 00:00:00 2001
From: "Gautham R. S
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
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"
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"
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"
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
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
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
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
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
>
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 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.
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
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
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"
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
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
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"
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
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"
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 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
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
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
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
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"
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
Hi Nicholas,
On Sun, Aug 06, 2017 at 03:02:38AM +1000, Nicholas Piggin wrote:
> POWER9 CPUs have independent MMU contexts per thread so KVM
> does not have to bring sibling threads into real-mode when
> switching MMU mode to guest. This can simplify POWER9 sleep/wake
> paths and avoids hwsyncs.
>
On Sun, Aug 06, 2017 at 03:02:39AM +1000, Nicholas Piggin wrote:
> Signed-off-by: Nicholas Piggin
Reviewed-by: Gautham R. Shenoy
--
Thanks and Regards
gautham.
On Sun, Aug 06, 2017 at 03:02:40AM +1000, Nicholas Piggin wrote:
> The hardware can execute stop in any context, and KVM does not
> require real mode. This saves a switch to real-mode when going
> idle.
>
> Signed-off-by: Nicholas Piggin
Acked-by: Gautham R. Shenoy
> -
do not have to be saved, and MSR does not have
> to be switched back to kernel MSR.
>
> So move the test for "lite" sleep states out to power9_idle_stop.
Nice optimization!
Reviewed-by: Gautham R. Shenoy
>
> Signed-off-by: Nicholas Piggin
> ---
&
On Tue, Aug 08, 2017 at 10:42:57PM +1000, Nicholas Piggin wrote:
> On Tue, 8 Aug 2017 16:06:43 +0530
> Gautham R Shenoy wrote:
>
> > Hi Nicholas,
> >
> > On Sun, Aug 06, 2017 at 03:02:38AM +1000, Nicholas Piggin wrote:
> > > POWER9 CPUs have independent MMU c
_limits_lock);
> ret = amd_pstate_set_energy_pref_index(cpudata, ret);
For drivers/cpufreq/amd-pstate.c
Acked-by: Gautham R. Shenoy
--
Thanks and Regards
gautham.
From: "Gautham R. Shenoy"
xive_find_target_in_mask() has the following for(;;) loop which has a
bug when @first == cpumask_first(@mask) and condition 1 fails to hold
for every CPU in @mask. In this case we loop forever in the for-loop.
first = cpu;
for (;;) {
if (cpu_
ntain consistent state and
> serialize operations.
>
> Fixes: 120496ac2d2d ("powerpc: Bring all threads online prior to
> migration/hibernation")
> Signed-off-by: Nathan Lynch
Looks good to me. This locking scheme makes the code consistent with
dlpar_cpu() which also
On Sat, Aug 3, 2019 at 1:03 AM Nathan Lynch wrote:
>
> rtas_cpu_state_change_mask() potentially operates on scores of cpus,
> so explicitly allow rescheduling in the loop body.
>
Are we seeing softlockups/rcu stalls while running this ?
> Signed-off-by: Nathan Lynch
Reviewe
Hello Sachin,
On Sat, Aug 24, 2019 at 09:34:41PM +0530, Sachin Sant wrote:
> linux-next is currently broken on POWER8 non virtualized. Kernel
> fails to reach login prompt with following kernel warning
> repeatedly shown during boot.
>
> The problem dates back atleast till next-20190816.
>
> [
From: "Gautham R. Shenoy"
Currently on Pseries Linux Guests, the offlined CPU can be put to one
of the following two states:
- Long term processor cede (also called extended cede)
- Returned to the Hypervisor via RTAS "stop-self" call.
This is controlled by the k
From: "Gautham R. Shenoy"
If a guest executes a stop instruction when the hypervisor has set the
PSSCR[ESL|EC] bits, the processor will throw an Hypervisor Facility
Unavailable exception. Currently when we receive this exception, we
only check if the exeception is generated due to
From: "Gautham R. Shenoy"
ISA v3.0 allows the guest to execute a stop instruction. For this, the
PSSCR[ESL|EC] bits need to be cleared by the hypervisor before
scheduling in the guest vCPU.
Currently we always schedule in a vCPU with PSSCR[ESL|EC] bits
set. This patch changes the be
From: "Gautham R. Shenoy"
*** RFC Only. Not intended for inclusion
Motivation
~~~
The POWER ISA v3.0 allows stop instruction to be executed from a Guest
Kernel (HV=0,PR=0) context. If the hypervisor has cleared
PSSCR[ESL|EC] bits, then the stop instru
From: "Gautham R. Shenoy"
The POWER ISA v3.0 allows stop instruction to be executed from a
HV=0,PR=0 context. If the PSSCR[ESL|EC] bits are cleared, then the
stop instruction thus executed will cause the thread to pause, thereby
donating its cycles to the other threads in the core
On Tue, Mar 31, 2020 at 05:40:55PM +0530, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy"
>
>
> *** RFC Only. Not intended for inclusion
>
> Motivation
> ~~~
>
> The POWER ISA v3.0 allows stop instruction to be executed from
Hello Naveen,
On Wed, Apr 01, 2020 at 03:28:48PM +0530, Naveen N. Rao wrote:
> Gautham R. Shenoy wrote:
> >From: "Gautham R. Shenoy"
> >
[..snip..]
> >-static DEVICE_ATTR(spurr, 0400, show_spurr, NULL);
> >-static DEVICE_ATTR(purr, 0400, show_purr, st
On Wed, Apr 01, 2020 at 03:12:53PM +0530, Naveen N. Rao wrote:
> Hi Gautham,
>
> Gautham R. Shenoy wrote:
> >From: "Gautham R. Shenoy"
> >
> >Currently when CPU goes idle, we take a snapshot of PURR via
> >pseries_idle_prolog() which is used at th
Hi Naveen,
On Thu, Apr 02, 2020 at 01:04:34PM +0530, Naveen N. Rao wrote:
[..snip..]
> >
> >It does reduce it to 10ms window. I am not sure if anyone samples PURR
> >etc faster than that rate.
> >
> >I measured how much time it takes to read the purr, spurr, idle_purr,
> >idle_spurr files back-to
On Fri, Apr 03, 2020 at 04:04:56PM +0530, Naveen N. Rao wrote:
> Gautham R Shenoy wrote:
> >On Wed, Apr 01, 2020 at 03:12:53PM +0530, Naveen N. Rao wrote:
> >>Hi Gautham,
> >>
> >>Gautham R. Shenoy wrote:
> >>>From: "Gautham R. Shenoy"
>
On Fri, Apr 03, 2020 at 12:20:26PM +1000, Nicholas Piggin wrote:
> Gautham R. Shenoy's on March 31, 2020 10:10 pm:
> > From: "Gautham R. Shenoy"
> >
> > ISA v3.0 allows the guest to execute a stop instruction. For this, the
> > PSSCR[ESL|EC] bits n
301 - 400 of 626 matches
Mail list logo
