Hello Mel,
On Mon, Apr 12, 2021 at 11:48:19AM +0100, Mel Gorman wrote:
> On Mon, Apr 12, 2021 at 11:06:19AM +0100, Valentin Schneider wrote:
> > On 12/04/21 10:37, Mel Gorman wrote:
> > > On Mon, Apr 12, 2021 at 11:54:36AM +0530, Srikar Dronamraju wrote:
> > >> * Gau
On Mon, Apr 12, 2021 at 06:33:55PM +0200, Michal Suchánek wrote:
> On Mon, Apr 12, 2021 at 04:24:44PM +0100, Mel Gorman wrote:
> > On Mon, Apr 12, 2021 at 02:21:47PM +0200, Vincent Guittot wrote:
> > > > > Peter, Valentin, Vincent, Mel, etal
> > > > >
> > > > > On architectures where we have multip
Hello Mel,
On Mon, Apr 12, 2021 at 04:24:44PM +0100, Mel Gorman wrote:
> On Mon, Apr 12, 2021 at 02:21:47PM +0200, Vincent Guittot wrote:
> > > > Peter, Valentin, Vincent, Mel, etal
> > > >
> > > > On architectures where we have multiple levels of cache access latencies
> > > > within a DIE, (For
(Missed cc'ing Cc Peter in the original posting)
On Fri, Apr 02, 2021 at 11:07:54AM +0530, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy"
>
> On POWER10 systems, the L2 cache is at the SMT4 small core level. The
> following commits ensure that L2 cache gets cor
From: "Gautham R. Shenoy"
On POWER10 systems, the L2 cache is at the SMT4 small core level. The
following commits ensure that L2 cache gets correctly discovered and
the Last-Level-Cache domain (LLC) is set to the SMT sched-domain.
790a166 powerpc/smp: Parse ibm,thread-groups wit
On Wed, Jan 20, 2021 at 09:54:20AM +, Mel Gorman wrote:
> On Wed, Jan 20, 2021 at 10:21:47AM +0100, Vincent Guittot wrote:
> > On Wed, 20 Jan 2021 at 10:12, Mel Gorman
> > wrote:
> > >
> > > On Wed, Jan 20, 2021 at 02:00:18PM +0530, Gautham R Shenoy wrot
Hello Mel, Peter,
On Tue, Jan 19, 2021 at 11:22:11AM +, Mel Gorman wrote:
> From: Peter Zijlstra (Intel)
>
> Both select_idle_core() and select_idle_cpu() do a loop over the same
> cpumask. Observe that by clearing the already visited CPUs, we can
> fold the iteration and iterate a core at a
From: "Gautham R. Shenoy"
Currently the cacheinfo code on powerpc indexes the "cache" objects
(modelling the L1/L2/L3 caches) where the key is device-tree node
corresponding to that cache. On some of the POWER server platforms
thread-groups within the core share different se
From: "Gautham R. Shenoy"
The helper function get_shared_cpu_map() was added in
'commit 500fe5f550ec ("powerpc/cacheinfo: Report the correct
shared_cpu_map on big-cores")'
and subsequently expanded upon in
'commit 0be47634db0b ("powerpc/cacheinfo: Pri
From: "Gautham R. Shenoy"
Hi,
Currently the cacheinfo code on powerpc indexes the "cache" objects
(modelling the L1/L2/L3 caches) where the key is device-tree node
corresponding to that cache. On some of the POWER server platforms
thread-groups within the core share differen
From: "Gautham R. Shenoy"
On platforms which have the "ibm,thread-groups" property, the per-cpu
variable cpu_l1_cache_map keeps a track of which group of threads
within the same core share the L1 cache, Instruction and Data flow.
This patch renames the variable to "thre
From: "Gautham R. Shenoy"
Hi,
This is the v2 of the patchset to extend parsing of "ibm,thread-groups" property
to discover the Shared-L2 cache information.
The previous versions can be found here :
v2 :
https://lore.kernel.org/linuxppc-dev/1607533700-5
From: "Gautham R. Shenoy"
On POWER systems, groups of threads within a core sharing the L2-cache
can be indicated by the "ibm,thread-groups" property array with the
identifier "2".
This patch adds support for detecting this, and when present, populate
the popul
From: "Gautham R. Shenoy"
On POWER platforms where only some groups of threads within a core
share the L2-cache (indicated by the ibm,thread-groups device-tree
property), we currently print the incorrect shared_cpu_map/list for
L2-cache in the sysfs.
This patch reports t
From: "Gautham R. Shenoy"
init_thread_group_l1_cache_map() initializes the per-cpu cpumask
thread_group_l1_cache_map with the core-siblings which share L1 cache
with the CPU. Make this function generic to the cache-property (L1 or
L2) and update a suitable mask. This is a preparatory
From: "Gautham R. Shenoy"
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can enco
From: "Gautham R. Shenoy"
On platforms which have the "ibm,thread-groups" property, the per-cpu
variable cpu_l1_cache_map keeps a track of which group of threads
within the same core share the L1 cache, Instruction and Data flow.
This patch renames the variable to "thre
From: "Gautham R. Shenoy"
On POWER platforms where only some groups of threads within a core
share the L2-cache (indicated by the ibm,thread-groups device-tree
property), we currently print the incorrect shared_cpu_map/list for
L2-cache in the sysfs.
This patch reports t
From: "Gautham R. Shenoy"
On POWER systems, groups of threads within a core sharing the L2-cache
can be indicated by the "ibm,thread-groups" property array with the
identifier "2".
This patch adds support for detecting this, and when present, populate
the popul
From: "Gautham R. Shenoy"
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can enco
From: "Gautham R. Shenoy"
Hi,
This is the v2 of the patchset to extend parsing of "ibm,thread-groups" property
to discover the Shared-L2 cache information.
The v1 can be found here :
https://lore.kernel.org/linuxppc-dev/1607057327-29822-1-git-send-email-...@
From: "Gautham R. Shenoy"
init_thread_group_l1_cache_map() initializes the per-cpu cpumask
thread_group_l1_cache_map with the core-siblings which share L1 cache
with the CPU. Make this function generic to the cache-property (L1 or
L2) and update a suitable mask. This is a preparatory
On Wed, Dec 09, 2020 at 02:09:21PM +0530, Srikar Dronamraju wrote:
> * Gautham R Shenoy [2020-12-08 23:26:47]:
>
> > > The drawback of this is even if cpus 0,2,4,6 are released L1 cache will
> > > not
> > > be released. Is this as expected?
> >
> >
On Wed, Dec 09, 2020 at 02:05:41PM +0530, Srikar Dronamraju wrote:
> * Gautham R Shenoy [2020-12-08 22:55:40]:
>
> > >
> > > NIT:
> > > tglx mentions in one of his recent comments to try keep a reverse fir tree
> > > ordering of variables where possib
On Mon, Dec 07, 2020 at 06:41:38PM +0530, Srikar Dronamraju wrote:
> * Gautham R. Shenoy [2020-12-04 10:18:47]:
>
> > From: "Gautham R. Shenoy"
> >
> >
> > Signed-off-by: Gautham R. Shenoy
> > ---
> >
> > +extern bool thread_group
Hello Srikar,
On Mon, Dec 07, 2020 at 06:10:39PM +0530, Srikar Dronamraju wrote:
> * Gautham R. Shenoy [2020-12-04 10:18:46]:
>
> > From: "Gautham R. Shenoy"
> >
> > On POWER systems, groups of threads within a core sharing the L2-cache
> > can be indic
Hello Srikar,
Thanks for taking a look at the patch.
On Mon, Dec 07, 2020 at 05:40:42PM +0530, Srikar Dronamraju wrote:
> * Gautham R. Shenoy [2020-12-04 10:18:45]:
>
> > From: "Gautham R. Shenoy"
>
>
>
> >
> > static int
From: "Gautham R. Shenoy"
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can enco
From: "Gautham R. Shenoy"
On POWER systems, groups of threads within a core sharing the L2-cache
can be indicated by the "ibm,thread-groups" property array with the
identifier "2".
This patch adds support for detecting this, and when present, populate
the popul
From: "Gautham R. Shenoy"
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can enco
From: "Gautham R. Shenoy"
On POWER platforms where only some groups of threads within a core
share the L2-cache (indicated by the ibm,thread-groups device-tree
property), we currently print the incorrect shared_cpu_map/list for
L2-cache in the sysfs.
This patch reports t
tal number of times the max
> - frequency is throttled due to 'OCC Reset'.
> + frequency is throttled due to 'OCC Reset'.
>
> The sysfs attributes representing different throttle reasons
> like
> powercap, overtemp, supply_fault, overcurrent and occ_reset map
> to
This hunk for the powernv cpufreq driver looks good to me.
For these two hunks,
Reviewed-by: Gautham R. Shenoy
On Wed, Sep 02, 2020 at 05:15:06PM +0530, Pratik Rajesh Sampat wrote:
> Measure cpuidle latencies on wakeup to determine and compare with the
> advertsied wakeup latencies for each idle state.
>
> Cpuidle wakeup latencies are determined for IPIs and Timer events and
> can help determine any deviat
On Wed, Sep 02, 2020 at 05:15:05PM +0530, Pratik Rajesh Sampat wrote:
> Changelog v3-->v4:
> 1. Overhaul in implementation from kernel module to a userspace selftest
> ---
>
> The patch series introduces a mechanism to measure wakeup latency for
> IPI and timer based interrupts
> The motivation b
From: "Gautham R. Shenoy"
commit d947fb4c965c ("cpuidle: pseries: Fixup exit latency for
CEDE(0)") sets the exit latency of CEDE(0) based on the latency values
of the Extended CEDE states advertised by the platform. The values
advertised by the platform are in timebase ticks.
Hello Joel,
On Wed, Sep 02, 2020 at 01:08:35AM +, Joel Stanley wrote:
> On Tue, 1 Sep 2020 at 14:09, Gautham R. Shenoy
> wrote:
> >
> > From: "Gautham R. Shenoy"
> >
> > commit d947fb4c965c ("cpuidle: pseries: Fixup exit latency for
> >
From: "Gautham R. Shenoy"
commit d947fb4c965c ("cpuidle: pseries: Fixup exit latency for
CEDE(0)") sets the exit latency of CEDE(0) based on the latency values
of the Extended CEDE states advertised by the platform. The values
advertised by the platform are in timebase ticks.
e, localize the sibling_mask variable to within the if
> condition.
>
> Cc: linuxppc-dev
> Cc: LKML
> Cc: Michael Ellerman
> Cc: Nicholas Piggin
> Cc: Anton Blanchard
> Cc: Oliver O'Halloran
> Cc: Nathan Lynch
> Cc: Michael Neuling
> Cc: Gautham R
Hi Srikar, Valentin,
On Wed, Jul 29, 2020 at 11:43:55AM +0530, Srikar Dronamraju wrote:
> * Valentin Schneider [2020-07-28 16:03:11]:
>
[..snip..]
> At this time the current topology would be good enough i.e BIGCORE would
> always be equal to a MC. However in future we could have chips that can
Cc: Anton Blanchard
> Cc: Oliver O'Halloran
> Cc: Nathan Lynch
> Cc: Michael Neuling
> Cc: Gautham R Shenoy
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Valentin Schneider
> Cc: Jordan Niethe
> Signed-off-by: Srikar Dronamraju
Reviewed-by: Gautham R. Shenoy
From: "Gautham R. Shenoy"
We are currently assuming that CEDE(0) has exit latency 10us, since
there is no way for us to query from the platform. However, if the
wakeup latency of an Extended CEDE state is smaller than 10us, then we
can be sure that the exit latency of CEDE(0) cann
From: "Gautham R. Shenoy"
This is a v3 of the patch series to parse the extended CEDE
information in the pseries-cpuidle driver.
The previous two versions of the patches can be found here:
v2:
https://lore.kernel.org/lkml/1596005254-25753-1-git-send-email-...@linux.vnet.ibm.com/
From: "Gautham R. Shenoy"
Currently we use CEDE with latency-hint 0 as the only other idle state
on a dedicated LPAR apart from the polling "snooze" state.
The platform might support additional extended CEDE idle states, which
can be discovered through the "ibm,get-sy
From: "Gautham R. Shenoy"
As per the PAPR, each H_CEDE call is associated with a latency-hint to
be passed in the VPA field "cede_latency_hint". The CEDE states that
we were implicitly entering so far is CEDE with latency-hint = 0.
This patch explicitly sets the latency h
From: "Gautham R. Shenoy"
As per the PAPR, each H_CEDE call is associated with a latency-hint to
be passed in the VPA field "cede_latency_hint". The CEDE states that
we were implicitly entering so far is CEDE with latency-hint = 0.
This patch explicitly sets the latency h
From: "Gautham R. Shenoy"
We are currently assuming that CEDE(0) has exit latency 10us, since
there is no way for us to query from the platform. However, if the
wakeup latency of an Extended CEDE state is smaller than 10us, then we
can be sure that the exit latency of CEDE(0) cann
From: "Gautham R. Shenoy"
Currently we use CEDE with latency-hint 0 as the only other idle state
on a dedicated LPAR apart from the polling "snooze" state.
The platform might support additional extended CEDE idle states, which
can be discovered through the "ibm,get-sy
From: "Gautham R. Shenoy"
Hi,
This is a v2 of the patch series to parse the extended CEDE
information in the pseries-cpuidle driver.
The v1 of this patchset can be found here :
https://lore.kernel.org/linuxppc-dev/1594120299-31389-1-git-send-email-...@linux.vnet.ibm.com/
The chan
Hello Rafael,
On Mon, Jul 27, 2020 at 04:14:12PM +0200, Rafael J. Wysocki wrote:
> On Tue, Jul 7, 2020 at 1:32 PM Gautham R Shenoy
> wrote:
> >
> > Hi,
> >
> > On Tue, Jul 07, 2020 at 04:41:34PM +0530, Gautham R. Shenoy wrote:
> > > Fr
ev
> Cc: LKML
> Cc: Michael Ellerman
> Cc: Nicholas Piggin
> Cc: Anton Blanchard
> Cc: Oliver O'Halloran
> Cc: Nathan Lynch
> Cc: Michael Neuling
> Cc: Gautham R Shenoy
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Valentin Schneider
> Cc: Jordan Niethe
> Cc: Michael Ellerman
> Cc: Nicholas Piggin
> Cc: Anton Blanchard
> Cc: Oliver O'Halloran
> Cc: Nathan Lynch
> Cc: Michael Neuling
> Cc: Gautham R Shenoy
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Valentin Schneider
> Cc: Jordan Niethe
&
if and only if shared_caches is set.
>
> Cc: linuxppc-dev
> Cc: LKML
> Cc: Michael Ellerman
> Cc: Nicholas Piggin
> Cc: Anton Blanchard
> Cc: Oliver O'Halloran
> Cc: Nathan Lynch
> Cc: Michael Neuling
> Cc: Gautham R Shenoy
> Cc: Ingo Molnar
> Cc: Peter
On Wed, Jul 22, 2020 at 12:27:47PM +0530, Srikar Dronamraju wrote:
> * Gautham R Shenoy [2020-07-22 11:51:14]:
>
> > Hi Srikar,
> >
> > > diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> > > index 72f16dc0cb26..57468877499a 100644
&
> Cc: Anton Blanchard
> Cc: Oliver O'Halloran
> Cc: Nathan Lynch
> Cc: Michael Neuling
> Cc: Gautham R Shenoy
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Valentin Schneider
> Cc: Jordan Niethe
> Signed-off-by: Srikar Dronamraju
Reviewed-by: Gautha
> domain.
>
> Cc: linuxppc-dev
> Cc: LKML
> Cc: Michael Ellerman
> Cc: Nicholas Piggin
> Cc: Anton Blanchard
> Cc: Oliver O'Halloran
> Cc: Nathan Lynch
> Cc: Michael Neuling
> Cc: Gautham R Shenoy
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc:
> Cc: Nathan Lynch
> Cc: Michael Neuling
> Cc: Anton Blanchard
> Cc: Gautham R Shenoy
> Cc: Vaidyanathan Srinivasan
> Cc: Jordan Niethe
> Signed-off-by: Srikar Dronamraju
Looks good to me.
Reviewed-by : Gautham R. Shenoy
> ---
> Changelog v1 -> v2:
>
ev
> Cc: LKML
> Cc: Michael Ellerman
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Valentin Schneider
> Cc: Nick Piggin
> Cc: Oliver OHalloran
> Cc: Nathan Lynch
> Cc: Michael Neuling
> Cc: Anton Blanchard
> Cc: Gautham R Shenoy
> Cc: Vaidyanathan Srinivasan
nar
> Cc: Peter Zijlstra
> Cc: Valentin Schneider
> Cc: Nick Piggin
> Cc: Oliver OHalloran
> Cc: Nathan Lynch
> Cc: Michael Neuling
> Cc: Anton Blanchard
> Cc: Gautham R Shenoy
> Cc: Vaidyanathan Srinivasan
> Cc: Jordan Niethe
> Signed-off-by: Srikar Dronamraj
if and only if shared_caches is set.
>
> Cc: linuxppc-dev
> Cc: LKML
> Cc: Michael Ellerman
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Valentin Schneider
> Cc: Nick Piggin
> Cc: Oliver OHalloran
> Cc: Nathan Lynch
> Cc: Michael Neuling
> Cc: Anton Bl
t; Cc: Peter Zijlstra
> Cc: Valentin Schneider
> Cc: Nick Piggin
> Cc: Oliver OHalloran
> Cc: Nathan Lynch
> Cc: Michael Neuling
> Cc: Anton Blanchard
> Cc: Gautham R Shenoy
> Cc: Vaidyanathan Srinivasan
> Cc: Jordan Niethe
> Signed-off-by: Srikar Dronamraju
>
> domain.
>
> Cc: linuxppc-dev
> Cc: LKML
> Cc: Michael Ellerman
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Valentin Schneider
> Cc: Nick Piggin
> Cc: Oliver OHalloran
> Cc: Nathan Lynch
> Cc: Michael Neuling
> Cc: Anton Blanchard
> Cc: Gautham R
LL_CONTEXT set, in other places the kernel uses the
> "deep" states as terminology. Hence renaming the variable to be coherent
> to its semantics.
>
> Signed-off-by: Pratik Rajesh Sampat
Acked-by: Gautham R. Shenoy
> ---
> arch/powerpc/platforms/powernv/idle.c | 18 +++
Hi,
On Wed, Jul 22, 2020 at 12:37:41AM +1000, Nicholas Piggin wrote:
> Excerpts from Pratik Sampat's message of July 21, 2020 8:29 pm:
> >
> >
> > On 20/07/20 5:27 am, Nicholas Piggin wrote:
> >> Excerpts from Pratik Rajesh Sampat's message of July 18, 2020 4:53 am:
> >>> Replace the variable na
Hi Pratik,
On Fri, Jul 17, 2020 at 02:48:01PM +0530, Pratik Rajesh Sampat wrote:
> This patch adds support to trace IPI based and timer based wakeup
> latency from idle states
>
> Latches onto the test-cpuidle_latency kernel module using the debugfs
> interface to send IPIs or schedule a timer b
ncrease the resolution of IPI wakeup]
>
> Signed-off-by: Pratik Rajesh Sampat
The debugfs module looks good to me.
Reviewed-by: Gautham R. Shenoy
> ---
> drivers/cpuidle/Makefile | 1 +
> drivers/cpuidle/test-cpuidle_latency.c | 150 +
>
On Mon, Jul 13, 2020 at 03:23:21PM +1000, Nicholas Piggin wrote:
> Excerpts from Pratik Rajesh Sampat's message of July 10, 2020 3:22 pm:
> > Changelog v1 --> v2:
> > 1. Save-restore DAWR and DAWRX unconditionally as they are lost in
> > shallow idle states too
> > 2. Rename pnv_first_spr_loss_leve
> check for machines lower than Power9
>
> Signed-off-by: Pratik Rajesh Sampat
Nice catch.
Reviewed-by: Gautham R. Shenoy
> ---
> arch/powerpc/platforms/powernv/idle.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/platfo
On Fri, Jul 03, 2020 at 06:16:40PM +0530, Pratik Rajesh Sampat wrote:
> Additional registers DAWR0, DAWRX0 may be lost on Power 10 for
> stop levels < 4.
Adding Ravi Bangoria to the cc.
> Therefore save the values of these SPRs before entering a "stop"
> state and restore their values on wakeup
Hi,
On Tue, Jul 07, 2020 at 04:41:34PM +0530, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy"
>
> Hi,
>
>
>
>
> Gautham R. Shenoy (5):
> cpuidle-pseries: Set the latency-hint before entering CEDE
> cpuidle-pseries: Add function to parse e
From: "Gautham R. Shenoy"
The Extended CEDE state with latency-hint = 1 is only different from
normal CEDE (with latency-hint = 0) in that a CPU in Extended CEDE(1)
does not wakeup on timer events. Both CEDE and Extended CEDE(1) map to
the same hardware idle state. Since we alrea
From: "Gautham R. Shenoy"
This patch exposes those extended CEDE states to the cpuidle framework
which are responsive to external interrupts and do not need an H_PROD.
Since as per the PAPR, all the extended CEDE states are non-responsive
to timers, we indicate this to the cpuidle sub
From: "Gautham R. Shenoy"
Hi,
On pseries Dedicated Linux LPARs, apart from the polling snooze idle
state, we currently have the CEDE idle state which cedes the CPU to
the hypervisor with latency-hint = 0.
However, the PowerVM hypervisor supports additional extended CEDE
states, wh
From: "Gautham R. Shenoy"
As per the PAPR, each H_CEDE call is associated with a latency-hint to
be passed in the VPA field "cede_latency_hint". The CEDE states that
we were implicitly entering so far is CEDE with latency-hint = 0.
This patch explicitly sets the latency h
From: "Gautham R. Shenoy"
Currently we use CEDE with latency-hint 0 as the only other idle state
on a dedicated LPAR apart from the polling "snooze" state.
The platform might support additional extended CEDE idle states, which
can be discovered through the "ibm,get-sy
From: "Gautham R. Shenoy"
We are currently assuming that CEDE(0) has exit latency 10us, since
there is no way for us to query from the platform. However, if the
wakeup latency of an Extended CEDE state is smaller than 10us, then we
can be sure that the exit latency of CEDE(0) cann
: Michael Ellerman
> Cc: Andrew Morton
> Cc: Linus Torvalds
> Cc: Gautham R Shenoy
> Cc: Satheesh Rajendran
> Cc: David Hildenbrand
> Signed-off-by: Srikar Dronamraju
This patch looks good to me.
Reviewed-by: Gautham R. Shenoy
--
Thanks and Regards
gautham.
per node.
>
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: linux...@kvack.org
> Cc: linux-kernel@vger.kernel.org
> Cc: Michal Hocko
> Cc: Mel Gorman
> Cc: Vlastimil Babka
> Cc: "Kirill A. Shutemov"
> Cc: Christopher Lameter
> Cc: Michael Ellerman
> Cc: Andrew Morton
man
> Cc: Andrew Morton
> Cc: Linus Torvalds
> Cc: Gautham R Shenoy
> Cc: Satheesh Rajendran
> Cc: David Hildenbrand
> Signed-off-by: Srikar Dronamraju
Looks good to me.
Reviewed-by: Gautham R. Shenoy
> ---
> Changelog v2:->v3:
> - Resolved comments from Gaut
x27;
>
> Fixes: 9c7b185ab2fe ("powernv/cpuidle: Parse dt idle properties into global
> structure")
> Signed-off-by: Christophe JAILLET
Thanks for catching this.
Reviewed-by: Gautham R. Shenoy
> ---
> arch/powerpc/platforms/powernv/idle.c | 2 +-
> 1 file
On Thu, Apr 30, 2020 at 09:46:13AM +0530, Gautham R Shenoy wrote:
> Hello Michael,
> > >
> > > Michael, could you please consider this for 5.8 ?
> >
> > Yes. Has it been tested on KVM at all?
>
> No. I haven't tested this on KVM. Will do that today.
Hello Michael,
On Thu, Apr 30, 2020 at 12:34:52PM +1000, Michael Ellerman wrote:
> Gautham R Shenoy writes:
> > On Mon, Apr 20, 2020 at 03:46:35PM -0700, Tyrel Datwyler wrote:
> >> On 4/7/20 1:47 AM, Gautham R. Shenoy wrote:
> >> > From: "Ga
Hello Srikar,
On Tue, Apr 28, 2020 at 03:08:35PM +0530, Srikar Dronamraju wrote:
> Node id queried from the static device tree may not
> be correct. For example: it may always show 0 on a shared processor.
> Hence prefer the node id queried from vphn and fallback on the device tree
> based node id
From: "Gautham R. Shenoy"
This is the v2 of the fix to change the default behaviour of cede_offline.
The previous version can be found here: https://lkml.org/lkml/2019/9/12/222
The main change from v1 is that the patch2 to create a sysfs file to
report and control th
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
On Wed, Sep 18, 2019 at 03:14:15PM +1000, Michael Ellerman wrote:
> "Gautham R. Shenoy" writes:
> > From: "Gautham R. Shenoy"
> >
> > Currently on Pseries Linux Guests, the offlined CPU can be put to one
> > of the following two states:
> >
Hello Nathan, Michael,
On Tue, Sep 17, 2019 at 12:36:35PM -0500, Nathan Lynch wrote:
> Gautham R Shenoy writes:
> > On Thu, Sep 12, 2019 at 10:39:45AM -0500, Nathan Lynch wrote:
> >> "Gautham R. Shenoy" writes:
> >> > The patchset also defines a new sy
Hello Nathan,
On Thu, Sep 12, 2019 at 10:39:45AM -0500, Nathan Lynch wrote:
> "Gautham R. Shenoy" writes:
> > The patchset also defines a new sysfs attribute
> > "/sys/device/system/cpu/cede_offline_enabled" on PSeries Linux guests
> > to allow userspac
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"
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"
Define a new sysfs attribute
"/sys/device/system/cpu/cede_offline_enabled" on PSeries Linux guests
to allow userspace programs to change the state into which the
offlined CPU need to be put to at runtime. This is intended for
userspace programs th
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_
Hi,
On Wed, May 15, 2019 at 01:15:52PM +0530, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy"
>
> The calls to arch_add_memory()/arch_remove_memory() are always made
> with the read-side cpu_hotplug_lock acquired via
> memory_hotplug_begin(). On p
Hi Abhishek,
On Wed, May 29, 2019 at 3:02 PM Abhishek Goel
wrote:
>
> To set frequency on specific cpus using cpupower, following syntax can
> be used :
> cpupower -c #i frequency-set -f #f -r
>
> While setting frequency using cpupower frequency-set command, if we use
> '-r' option, it is expecte
Hi Nicholas,
On Thu, May 16, 2019 at 04:13:17PM +1000, Nicholas Piggin wrote:
>
> > The motivation behind this patch was a HPC customer issue where they
> > were observing some CPUs in the core getting stuck at stop0_lite
> > state, thereby lowering the performance on the other CPUs of the core
Hello Nicholas,
On Thu, May 16, 2019 at 02:55:42PM +1000, Nicholas Piggin wrote:
> Abhishek's on May 13, 2019 7:49 pm:
> > On 05/08/2019 10:29 AM, Nicholas Piggin wrote:
> >> Abhishek Goel's on April 22, 2019 4:32 pm:
> >>> Currently, the cpuidle governors determine what idle state a idling CPU
>
From: "Gautham R. Shenoy"
The calls to arch_add_memory()/arch_remove_memory() are always made
with the read-side cpu_hotplug_lock acquired via
memory_hotplug_begin(). On pSeries,
arch_add_memory()/arch_remove_memory() eventually call resize_hpt()
which in turn calls stop_machi
On Tue, May 14, 2019 at 05:02:16PM +1000, Michael Ellerman wrote:
> "Gautham R. Shenoy" writes:
> > From: "Gautham R. Shenoy"
> >
> > Subject: Re: [RESEND PATCH] powerpc/pseries: Fix cpu_hotplug_lock
> > acquisition in resize_hpt
>
> ps.
Hi Michael,
On Tue, May 14, 2019 at 05:00:19PM +1000, Michael Ellerman wrote:
> "Gautham R. Shenoy" writes:
> > From: "Gautham R. Shenoy"
> >
> > During a memory hotplug operations involving resizing of the HPT, we
> > invoke a stop_machine()
From: "Gautham R. Shenoy"
In cpu_to_drc_index() in the case when FW_FEATURE_DRC_INFO is absent,
we currently use of_read_property() to obtain the pointer to the array
corresponding to the property "ibm,drc-indexes". The elements of this
array are of type __be32, but are
Hi Shilpa,
On Thu, Feb 28, 2019 at 11:25:25AM +0530, Shilpasri G Bhat wrote:
> Hi,
>
> On 02/28/2019 10:14 AM, Daniel Axtens wrote:
> > Shilpasri G Bhat writes:
> >
> >> In POWER9, OCC(On-Chip-Controller) provides for hard and soft system
> >> powercapping range. The hard powercap range is guar
1 - 100 of 525 matches
Mail list logo
