n this, but who knows.
>
> Signed-off-by: Peter Zijlstra (Intel)
This naming makes sense.
Acked-by: Gautham R. Shenoy
--
Thanks and Regards
gautham.
er Zijlstra (Intel)
Reviewed-by: Gautham R. Shenoy
> ---
> arch/arm/mach-imx/cpuidle-imx6q.c|4 +--
> arch/arm/mach-imx/cpuidle-imx6sx.c |4 +--
> arch/arm/mach-omap2/cpuidle34xx.c|4 +--
> arch/arm/mach-omap2/cpuidle44xx.c|8 +++---
> drivers
ch
> Cc: Michael Ellerman
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Valentin Schneider
> Cc: Gautham R Shenoy
> Cc: Vincent Guittot
> Fixes: c1e53367dab1 ("powerpc/smp: Cache CPU to chip lookup")
> Reported-by: Aneesh Kumar K.V
> Debugged-by: Michael E
Hello Srikar,
On Sat, Aug 21, 2021 at 02:54:19PM +0530, Srikar Dronamraju wrote:
[..snip..]
The patch looks good to me.
Reviewed-by: Gautham R. Shenoy
> ---
> arch/powerpc/kernel/smp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kern
lways greater than
> threads_per_core. However this may not be true when using nr_cpus=2 or
> similar options. Handle the case where num_possible_cpus is smaller than
> threads_per_core.
>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: Aneesh Kumar K.V
> Cc: Nathan Lynch
> Cc
blings.
> Hence, create a new thread_group_l3_cache_map to keep list of L3 siblings,
> but fill the mask using same property "2" array.
This version looks good to me.
Reviewed-by: Gautham R. Shenoy
>
> Signed-off-by: Parth Shah
> ---
> arch/powerpc/include/asm/smp.h |
for all chips */
> + chip_cpu_mask = kcalloc(32, sizeof(cpumask_t), GFP_KERNEL);
I suppose by 32 you mean the maximum number of chips possible. You
could use a #define for that.
Otherwise, the patch looks good to me.
Reviewed-by: Gautham R. Shenoy
> + if (!chip_
Hi Parth,
Sorry for the late review.
On Tue, Jun 15, 2021 at 12:38:04PM +0530, Parth Shah wrote:
> On POWER10 systems, the "ibm,thread-groups" property "2" indicates the cpus
> in thread-group share both L2 and L3 caches. Hence, use cache_property = 2
> itself to find both the L2 and L3 cache
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
On POWER9 LPARs, the firmwares advertise a very low value o
From: "Gautham R. Shenoy"
Currently in fixup_cede0_latency() code, we perform the fixup the
CEDE(0) exit latency value only if minimum advertized extended CEDE
latency values are less than 10us. This was done so as to not break
the expected behaviour on POWER8 platforms where the
From: "Gautham R. Shenoy"
Hi,
This is the v5 of the patchset to fixup CEDE0 latency only from
POWER10 onwards.
The previous versions of the patches are
v4 :
https://lore.kernel.org/linux-pm/1623048014-16451-1-git-send-email-...@linux.vnet.ibm.com/
v3 :
https://lore.kernel.org/li
esi_buf;
> + num_attrs = be64_to_cpu(esi_hdr->num_attrs);
Shouldn't we check for the esi_hdr->data_header_version here?
Currently we are only aware of the version 1. If we happen to run this
kernel code on a future platform which supports a different version,
wouldn't it be safer to bail out here ?
Otherwise this patch looks good to me.
Reviewed-by: Gautham R. Shenoy
--
Thanks and Regards
gautham.
Hello Pratik,
On Tue, Jun 15, 2021 at 10:39:49AM +0530, Pratik R. Sampat wrote:
> In the numa=off kernel command-line configuration init_chip_info() loops
> around the number of chips and attempts to copy the cpumask of that node
> which is NULL for all iterations after the first chip.
Thanks
On Wed, Jun 16, 2021 at 07:12:40PM +0530, Pratik R. Sampat wrote:
> Adds a generic interface to represent the energy and frequency related
> PAPR attributes on the system using the new H_CALL
> "H_GET_ENERGY_SCALE_INFO".
>
> H_GET_EM_PARMS H_CALL was previously responsible for exporting this
>
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
On POWER9 LPARs, the firmwares advertise a very low value o
Hello Michael,
On Thu, Apr 29, 2021 at 07:56:25PM +1000, Michael Ellerman wrote:
> "Gautham R. Shenoy" writes:
> > From: "Gautham R. Shenoy"
> >
> > Commit d947fb4c965c ("cpuidle: pseries: Fixup exit latency for
> > CEDE(0)") set
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
On POWER9 LPARs, the firmwares advertise a very low value o
Hello Michal,
On Wed, Apr 28, 2021 at 10:03:26AM +0200, Michal Suchánek wrote:
> >
> That's a nice detailed explanation. Maybe you could summarize it in the
> commit message so that people looking at the patch in the future can
> tell where the value comes from.
Sure, I will do that and send a
anathan Srinivasan wrote:
> > > > * Michal Such?nek [2021-04-23 19:45:05]:
> > > >
> > > > > On Fri, Apr 23, 2021 at 09:29:39PM +0530, Vaidyanathan Srinivasan
> > > > > wrote:
> > > > > > * Michal Such?nek [2021-04-23 09:35:5
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
On some of the POWER9 LPARs, the older firmwares advert
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 Thu, Apr 15, 2021 at 11:21:10PM +0530, Srikar Dronamraju wrote:
> * Gautham R Shenoy [2021-04-15 22:49:21]:
>
> > >
> > > +int *chip_id_lookup_table;
> > > +
> > > #ifdef CONFIG_PPC64
> > > int __initdata iommu_is_off;
> > &
; Cc: qemu-...@nongnu.org
> Cc: Cedric Le Goater
> Cc: David Gibson
> Cc: Nathan Lynch
> Cc: Michael Ellerman
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Valentin Schneider
> Cc: Gautham R Shenoy
> Reported-by: Daniel Henrique Barboza
> Signed-off-by: Sri
Hi Srikar,
On Thu, Apr 15, 2021 at 05:39:32PM +0530, Srikar Dronamraju wrote:
[..snip..]
> @@ -1485,12 +1486,36 @@ static void add_cpu_to_masks(int cpu)
> add_cpu_to_smallcore_masks(cpu);
>
> /* In CPU-hotplug path, hence use GFP_ATOMIC */
> - alloc_cpumask_var_node(,
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
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 get
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 Sat, Jan 30, 2021 at 11:08:17PM +1000, Nicholas Piggin wrote:
> Like other interrupt handler conversions, switch to getting registers
> from the pt_regs argument.
>
> Signed-off-by: Nicholas Piggin
> ---
> arch/powerpc/kernel/head_fsl_booke.S | 6 +++---
> arch/powerpc/kernel/traps.c
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"
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: Print correct cach
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 differen
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 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 "
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 prepara
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 po
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"
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 "
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 po
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"
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 prepara
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 po
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 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 po
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
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
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
> &g
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.
code. The POWER10 deep sleep code
> (e.g., the BHRB restore) has been taken out, but it can be re-added
> when stop > 3 support is added.
MMCRA[BHRB] save/restore was in the shallow stop-state path. But we
can add it back later.
>
> Cc: Ryan P Grimm
> Cc: Michael Neuling
&
here, 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 Sheno
signed int nid;
> +
> chips[i].id = chip[i];
> - cpumask_copy([i].mask, cpumask_of_node(chip[i]));
> + /*
> + * On powervn platforms firmware group id is same as chipd id.
But doesn't hurt to be safe :-)
Reviewed-by: Gautham R. Shenoy
>
y cleanup.")
> Cc: sta...@vger.kernel.org # v3.14
> Signed-off-by: Joel Stanley
Sorry I missed this v2.
The patch looks good to me.
Acked-by: Gautham R. Shenoy
> --
> v2:
> Use pr_warn instead of WARN
> Reword and print proccess name with pid in message
> Leave CPU
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
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
&g
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"
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"
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 latenc
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"
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
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 latenc
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
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
gt; 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
> Sign
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
> Signed
ask 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 Zijl
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: Gautham R.
> 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: Va
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:
> pow
gt; 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
ask 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
E_FULL_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
ie, on explicit need from user. Also save/restore MMCRA in the
> restore path of state-loss idle state to make sure we keep BHRB disabled
> if it was not enabled on request at runtime.
>
> Signed-off-by: Athira Rajeev
For arch/powerpc/platforms/powernv/idle.c
Reviewed-by: Gauth
Hi Srikar,
On Mon, Jul 20, 2020 at 11:18:16AM +0530, Srikar Dronamraju wrote:
> * Gautham R Shenoy [2020-07-17 13:56:53]:
>
> > On Tue, Jul 14, 2020 at 10:06:23AM +0530, Srikar Dronamraju wrote:
> > > Lookup the coregroup id from the associativity array.
> > &
On Mon, Jul 20, 2020 at 11:49:11AM +0530, Srikar Dronamraju wrote:
> * Gautham R Shenoy [2020-07-17 12:07:55]:
>
> > On Tue, Jul 14, 2020 at 10:06:19AM +0530, Srikar Dronamraju wrote:
> > > Currently "CACHE" domain happens to be the 2nd sched domain as per
>
Hi Srikar,
On Mon, Jul 20, 2020 at 12:15:04PM +0530, Srikar Dronamraju wrote:
> * Gautham R Shenoy [2020-07-17 11:30:11]:
>
> > Hi Srikar,
> >
> > On Tue, Jul 14, 2020 at 10:06:18AM +0530, Srikar Dronamraju wrote:
> > > Current code assumes that cpumas
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
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 +
>
loran
> Cc: Nathan Lynch
> Cc: Michael Neuling
> Cc: Anton Blanchard
> Cc: Gautham R Shenoy
> Cc: Vaidyanathan Srinivasan
> Signed-off-by: Srikar Dronamraju
We need this documented in the
Documentation/admin-guide/kernel-parameters.txt
Other than that, the patch
smallest coregroup, which currently
> corresponds to the penultimate domain in the device-tree.
>
> Cc: linuxppc-dev
> Cc: Michael Ellerman
> Cc: Nick Piggin
> Cc: Oliver OHalloran
> Cc: Nathan Lynch
> Cc: Michael Neuling
> Cc: Anton Blanchard
> Cc: Gautha
On Fri, Jul 17, 2020 at 01:49:26PM +0530, Gautham R Shenoy wrote:
> > +int cpu_to_coregroup_id(int cpu)
> > +{
> > + return cpu_to_core_id(cpu);
> > +}
>
>
> So, if has_coregroup_support() returns true, then since the core_group
> identification i
lerman
> Cc: Nick Piggin
> Cc: Oliver OHalloran
> Cc: Nathan Lynch
> Cc: Michael Neuling
> Cc: Anton Blanchard
> Cc: Gautham R Shenoy
> Cc: Vaidyanathan Srinivasan
> Signed-off-by: Srikar Dronamraju
> ---
> arch/powerpc/include/asm/topology.h | 10
Piggin
> Cc: Oliver OHalloran
> Cc: Nathan Lynch
> Cc: Michael Neuling
> Cc: Anton Blanchard
> Cc: Gautham R Shenoy
> Cc: Vaidyanathan Srinivasan
> Signed-off-by: Srikar Dronamraju
Good fix.
Reviewed-by: Gautham R. Shenoy
> ---
> arch/powerpc/kernel/smp.c |
c: linuxppc-dev
> Cc: Michael Ellerman
> Cc: Nick Piggin
> Cc: Oliver OHalloran
> Cc: Nathan Lynch
> Cc: Michael Neuling
> Cc: Anton Blanchard
> Cc: Gautham R Shenoy
> Cc: Vaidyanathan Srinivasan
> Signed-off-by: Srikar Dronamraju
This looks good to me from the discove
; Cc: Nathan Lynch
> Cc: Michael Neuling
> Cc: Anton Blanchard
> Cc: Gautham R Shenoy
> Cc: Vaidyanathan Srinivasan
> Signed-off-by: Srikar Dronamraju
> ---
> arch/powerpc/kernel/smp.c | 48 +++
> 1 file changed, 34 inserti
t; Cc: Nick Piggin
> Cc: Oliver OHalloran
> Cc: Nathan Lynch
> Cc: Michael Neuling
> Cc: Anton Blanchard
> Cc: Gautham R Shenoy
> Cc: Vaidyanathan Srinivasan
> Signed-off-by: Srikar Dronamraju
> ---
> arch/powerpc/kernel/smp.c | 28 +++
1 - 100 of 622 matches
Mail list logo
