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
> <e...@linux.vnet.ibm.com> wrote:
> > From: "Gautham R. Shenoy" <e...@linux.vnet.ibm.com>
> >
> > On POWERNV
Hi Michael,
On Wed, Dec 06, 2017 at 09:54:27PM +1100, Michael Ellerman wrote:
> Shilpasri G Bhat <shilpa.b...@linux.vnet.ibm.com> writes:
>
> > From: "Gautham R. Shenoy" <e...@linux.vnet.ibm.com>
> >
> > Pstates are 8bit values but on POWER8 they ar
From: "Gautham R. Shenoy" <e...@linux.vnet.ibm.com>
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
From: "Gautham R. Shenoy" <e...@linux.vnet.ibm.com>
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 threa
From: "Gautham R. Shenoy" <e...@linux.vnet.ibm.com>
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 SM
Hello Michael,
On Fri, May 18, 2018 at 11:14:04PM +1000, Michael Ellerman wrote:
> Gautham R Shenoy <e...@linux.vnet.ibm.com> writes:
> ...
> >> > @@ -565,7 +615,16 @@ void __init smp_setup_cpu_maps(void)
> >> > vdso_data->processorCou
Hello Michael,
On Fri, May 18, 2018 at 11:21:22PM +1000, Michael Ellerman wrote:
> "Gautham R. Shenoy" <e...@linux.vnet.ibm.com> writes:
>
> > diff --git a/arch/powerpc/kernel/setup-common.c
> > b/arch/powerpc/kernel/setup-common.c
> > index 0af5c11..884d
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" <e...@linux.vnet.ibm.com>
> >
> > Each of the SMT4 cores forming a fused-core are more or less
>
From: "Gautham R. Shenoy"
The commit 78eaa10f027c ("cpuidle: powernv/pseries: Auto-promotion of
snooze to deeper idle state") introduced a timeout for the snooze idle
state so that it could be eventually be promoted to a deeper idle
state. The snooze timeout value is static a
Hi Balbir,
Thanks for reviewing the patch!
On Fri, Jun 01, 2018 at 12:51:05AM +1000, Balbir Singh wrote:
> On Thu, May 31, 2018 at 10:15 PM, Gautham R. Shenoy
[..snip..]
> >
> > +static u64 get_snooze_timeout(struct cpuidle_device *dev,
> > +
Hello Michael,
On Mon, Jun 04, 2018 at 09:27:40PM +1000, Michael Ellerman wrote:
> "Gautham R. Shenoy" writes:
>
> > From: "Gautham R. Shenoy"
> >
> > The commit 78eaa10f027c ("cpuidle: powernv/pseries: Auto-promotion of
> > snooze to
Hi Akshay,
On Tue, Jun 19, 2018 at 10:34:26AM +0530, Akshay Adiga wrote:
> Device-tree parsing happens in twice, once while deciding idle state to
> be used for hotplug and once during cpuidle init. Hence, parsing the
> device tree and caching it will reduce code duplication. Parsing code
> has
Hi Akshay,
On Tue, Jun 19, 2018 at 10:34:28AM +0530, Akshay Adiga wrote:
> Export pnv_idle_states and nr_pnv_idle_states so that its accessible to
> cpuidle driver. Use properties from pnv_idle_states structure for powernv
> cpuidle_init.
>
> Signed-off-by: Akshay Adiga
> ---
>
Hi Akshay,
On Tue, Jun 19, 2018 at 10:34:27AM +0530, Akshay Adiga wrote:
> The required data is accessible from cpuidle_states structure and
> nr_cpu_idle_states. This patch makes changes to avoid reparsing and use
> data from these structures.
>
> Signed-off-by: Akshay Adiga
> ---
>
has been
> moved to pnv_parse_cpuidle_dt() from pnv_probe_idle_states(). In addition
> to the properties in the device tree the number of available states is
> also required.
>
> Signed-off-by: Akshay Adiga
> Reviewed-by: Nicholas Piggin
Looks good.
Reviewed-by: Gautham R. Shenoy
g the
residency values in the kernel.
Otherwise looks good to me.
Reviewed-by: Gautham R. Shenoy
--
Thanks and Regards
gautham.
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 cach
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
From: "Gautham R. Shenoy"
Hi,
This is the second iteration of the patchset to add support for big-core on
POWER9.
The earlier version can be found here: https://lkml.org/lkml/2018/5/11/245.
The changes from the previous version:
- Added comments explaining the "ibm,thread
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 <r...@rjwysocki.net> wrote:
> > On Monday, December 18, 2017 9:38:20 AM CET Gautham R Shenoy wrote:
> >> Hi Balbir,
> >>
> >>
From: "Gautham R. Shenoy"
Hi,
This is the fifth 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:
v5: https://lkml.org/lkml/2018/8/6/587
v4: https://lkm
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
Hello Nicholas,
On Fri, Aug 03, 2018 at 12:05:47AM +1000, Nicholas Piggin wrote:
> On Thu, 2 Aug 2018 10:21:32 +0530
> Akshay Adiga wrote:
>
> > From: Abhishek Goel
> >
> > If a state has "opal-supported" compat flag in device-tree, an opal call
> > needs to be made during the entry and exit
From: "Gautham R. Shenoy"
Each of the SMT4 cores forming a big-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.
This patch achieves this
alse;
> +
> + memset(, 0, sizeof(sprs));
> +
> + if (!(psscr & (PSSCR_EC|PSSCR_ESL))) {
> + BUG_ON(!mmu_on);
> +
> + /*
> + * Wake synchronously. SRESET via xscom may still cause
> + * a 0x100 powersave wakeup with SRR1 reason!
> + */
> + srr1 = isa3_idle_stop_noloss(psscr);
> + if (likely(!srr1))
> + return 0;
> +
We come here if if we were woken up from a ESL=0 stop by a xscom
SRESET. Where would the SRESET be handled ?
> + /*
> + * Registers not saved, can't recover!
> + * This would be a hardware bug
> + */
> + BUG_ON((srr1 & SRR1_WAKESTATE) != SRR1_WS_NOLOSS);
> +
> + goto out;
> + }
> +
The patch looks good otherwise, especially the idle_book3s.S :-)
Reviewed-by: Gautham R. Shenoy
--
Thanks and Regards
gautham.
Hello Michael,
On Tue, Aug 07, 2018 at 10:15:37PM +1000, Michael Ellerman wrote:
> > Skiboot patch-set for device-tree is posted here :
> > https://patchwork.ozlabs.org/project/skiboot/list/?series=58934
>
> I don't see a device tree binding documented anywhere?
>
> There is an existing binding
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
On Thu, Aug 09, 2018 at 06:26:57AM -0700, Srikar Dronamraju wrote:
> * Gautham R. Shenoy [2018-08-09 11:02:08]:
>
> >
> > 3) ppc64_cpu --smt=2
> >SMT domain ceases to exist as each domain consists of just one
> >group.
> >
>
> When seen in
Hi Srikar,
Thanks for reviewing the patch.
On Thu, Aug 09, 2018 at 06:27:43AM -0700, Srikar Dronamraju wrote:
> * Gautham R. Shenoy [2018-08-09 11:02:07]:
>
> >
> > int threads_per_core, threads_per_subcore, threads_shift;
> > +bool has_big_cores;
> >
From: "Gautham R. Shenoy"
Each of the SMT4 cores forming a big-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.
This patch achieves this
From: "Gautham R. Shenoy"
Hi,
This is the fifth iteration of the patchset to add support for
big-core on POWER9.
The previous versions can be found here:
v4: https://lkml.org/lkml/2018/7/24/79
v3: https://lkml.org/lkml/2018/7/6/255
v2: https://lkml.org/lkml/2018/7/3/401
v1: https:
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
From: "Gautham R. Shenoy"
Each of the SMT4 cores forming a big-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.
This patch achieves this
From: "Gautham R. Shenoy"
Hi,
This is the seventh 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:
v6: https://lkml.org/lkml/2018/8/9/119
v5: https://lkm
From: "Gautham R. Shenoy"
On 64-bit servers, SPRN_SPRG3 and its userspace read-only mirror
SPRN_USPRG3 are used as userspace VDSO write and read registers
respectively.
SPRN_SPRG3 is lost when we enter stop4 and above, and is currently not
restored. As a result, any read from S
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
> > ---
From: "Gautham R. Shenoy"
On 64-bit servers, SPRN_SPRG3 and its userspace read-only mirror
SPRN_USPRG3 are used as userspace VDSO write and read registers
respectively.
SPRN_SPRG3 is lost when we enter stop4 and above, and is currently not
restored. As a result, any read from S
rong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Gautham-R-Shenoy/powerpc-Detect-the-presence-of-big-cores-via-ibm-thread-groups/20180706-174756
> base: https://git.kernel.org/pub/scm/linux/kernel/git/powe
From: "Gautham R. Shenoy"
Hi,
This is the fourth iteration of the patchset to add support for
big-core on POWER9.
The previous versions can be found here:
v3: https://lkml.org/lkml/2018/7/6/255
v2: https://lkml.org/lkml/2018/7/3/401
v1: https://lkml.org/lkml/2018/5/11/245
Changes :
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 cach
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
Hello Nicholas,
On Sat, Jul 21, 2018 at 02:29:24PM +1000, Nicholas Piggin wrote:
> Reimplement Book3S idle code to C, in the powernv platform code.
> Assembly stubs are used to save and restore the stack frame and
> non-volatile GPRs before going to idle, but these are small and
> mostly agnostic
From: "Gautham R. Shenoy"
On 64-bit Servers, SPRN_SPRG3 and its userspace read-only mirror
SPRN_USPRG3 are used as userspace VDSO write and read registers
respectively.
SPRN_SPRG3 is lost when we enter stop4 and above, and is currently not
restored. As a result, any read from S
On Tue, Jul 17, 2018 at 04:57:29PM +0530, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy"
>
> On 64-bit Servers, SPRN_SPRG3 and its userspace read-only mirror
> SPRN_USPRG3 are used as userspace VDSO write and read registers
> respectively.
>
> SPRN_SP
Hello Murilo,
Thanks for reviewing the patch. Replies inline.
On Tue, Jul 03, 2018 at 02:16:55PM -0300, Murilo Opsfelder Araujo wrote:
> On Tue, Jul 03, 2018 at 04:33:50PM +0530, Gautham R. Shenoy wrote:
> > From: "Gautham R. Shenoy"
> >
> > On IBM POWER9, the
Hi Murilo,
Thanks for the review.
On Tue, Jul 03, 2018 at 02:53:46PM -0300, Murilo Opsfelder Araujo wrote:
[..snip..]
> > -/* Initialize CPU <=> thread mapping/
> > + if (has_interleaved_big_core) {
> > + int key = __builtin_ctzl(CPU_FTR_ASYM_SMT);
> > +
> > +
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
From: "Gautham R. Shenoy"
Hi,
This is the third iteration of the patchset to add support for
big-core on POWER9.
The previous versions can be found here:
v2: https://lkml.org/lkml/2018/7/3/401
v1: https://lkml.org/lkml/2018/5/11/245
Changes : v2 --> v3
- Set sane val
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 cach
Hello Nicholas,
On Mon, Jul 09, 2018 at 12:24:36AM +1000, Nicholas Piggin wrote:
> Reimplement POWER9 idle code in C, in the powernv platform code.
> Assembly stubs are used to save and restore the stack frame and
> non-volatile GPRs before going to idle, but these are small and
> mostly
On Wed, Jul 11, 2018 at 06:30:36PM +1000, Nicholas Piggin wrote:
> On Tue, 10 Jul 2018 16:36:34 +0530
> Gautham R Shenoy wrote:
>
> > Hello Nicholas,
> >
> >
> > On Mon, Jul 09, 2018 at 12:24:36AM +1000, Nicholas Piggin wrote:
> > > Reimplement POWE
Hello Murilo,
On Sun, Jul 08, 2018 at 01:03:34PM -0300, Murilo Opsfelder Araujo wrote:
> On Fri, Jul 06, 2018 at 02:35:48PM +0530, Gautham R. Shenoy wrote:
> > From: "Gautham R. Shenoy"
> >
> > On IBM POWER9, the device tree exposes a property array identifed b
On Fri, Sep 28, 2018 at 03:36:08PM -0500, Nathan Fontenot wrote:
> On 09/28/2018 02:02 AM, Gautham R Shenoy wrote:
> > Hi Nathan,
> >
> > On Thu, Sep 27, 2018 at 12:31:34PM -0500, Nathan Fontenot wrote:
> >> On 09/27/2018 11:51 AM, Gautham R. Shenoy wrote:
Hi Nathan,
On Thu, Sep 27, 2018 at 12:31:34PM -0500, Nathan Fontenot wrote:
> On 09/27/2018 11:51 AM, Gautham R. Shenoy wrote:
> > From: "Gautham R. Shenoy"
> >
> > Live Partition Migrations require all the present CPUs to execute the
> > H_JOIN call, and he
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
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"
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"
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"
Live Partition Migrations require all the present CPUs to execute the
H_JOIN call, and hence rtas_ibm_suspend_me() onlines any offline CPUs
before initiating the migration for this purpose.
The commit 85a88cabad57
("powerpc/pseries: Disable CPU
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
From: "Gautham R. Shenoy"
Hi,
This is the ninth 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:
v8: https://lkml.org/lkml/2018/9/20/899
v7: https://lkm
From: "Gautham R. Shenoy"
This patch adds two sysfs attributes named smallcore_thread_siblings
and smallcore_thread_siblings_list to the "topology" attribute group
for each CPU device.
The read-only attributes
/sys/device/system/cpu/cpuN/topology/smallcore_thread_siblings an
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
Hello Dave,
On Mon, Oct 01, 2018 at 07:05:11AM -0700, Dave Hansen wrote:
> On 10/01/2018 06:16 AM, Gautham R. Shenoy wrote:
> >
> > Patch 3: Creates a pair of sysfs attributes named
> > /sys/devices/system/cpu/cpuN/topology/smallcore_thread_siblings
> >
Hi Michael,
On Mon, Sep 24, 2018 at 05:00:42PM +1000, Michael Ellerman wrote:
> Nathan Fontenot writes:
> > On 09/18/2018 05:32 AM, Gautham R Shenoy wrote:
> >> Hi Nathan,
> >> On Tue, Sep 18, 2018 at 1:05 AM Nathan Fontenot
> >> wrote:
> >>>
Hi Dave,
On Thu, Sep 20, 2018 at 11:04:54AM -0700, Dave Hansen wrote:
> On 09/20/2018 10:22 AM, Gautham R. Shenoy wrote:
> >-
> >|L1 Cache |
> >
- X8-
>From acb9eb9f8bb14cf3121aeb0589255cbc31292be7 Mon Sep 17 00:00:00 2001
From: "Gautham R. Shenoy"
Date: Tue, 25 Sep 2018 11:01:18 +0530
Subject: [PATCH] powerpc/rtas: Fix a potential race between CPU-Offline &
Migration
commit 85a88cabad57 ("pow
Hello Dave,
On Tue, Sep 25, 2018 at 03:16:30PM -0700, Dave Hansen wrote:
> On 09/22/2018 04:03 AM, Gautham R Shenoy wrote:
> > Without this patchset, the SMT domain would be defined as the group of
> > threads that share L2 cache.
>
> Could you try to make a more clear, co
From: "Gautham R. Shenoy"
This patch adds two sysfs attributes named smallcore_thread_siblings
and smallcore_thread_siblings_list to the "topology" attribute group
for each CPU device.
The read-only attributes
/sys/device/system/cpu/cpuN/topology/smallcore_thread_siblings an
From: "Gautham R. Shenoy"
Each of the SMT4 cores forming a big-core are more or less independent
units. Thus when multiple tasks are scheduled to run on the big-core,
we get the best performance when the tasks are spread across the pair of
SMT4 cores.
This patch achieves this by setti
From: "Gautham R. Shenoy"
Hi,
This is the eight 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:
v7: https://lkml.org/lkml/2018/8/20/52
v6: https://lkm
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
work?
-X8--
>From 6699ce205730d3d45ea79015751880740e9b Mon Sep 17 00:00:00 2001
From: "Gautham R. Shenoy"
Date: Fri, 21 Sep 2018 22:43:05 +0530
Subject: [PATCH] powerpc/smp: Initialize thread_groups local variable
Signed-off-b
rong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Gautham-R-Shenoy/powerpc-Detection-and-scheduler-optimization-for-POWER9-bigcore/20180921-085812
> base: https://git.kernel.org/pub/scm/linux/kernel/git/powe
From: "Gautham R. Shenoy"
Live Partition Migrations require all the present CPUs to execute the
H_JOIN call, and hence rtas_ibm_suspend_me() onlines any offline CPUs
before initiating the migration for this purpose.
The commit 85a88cabad57
("powerpc/pseries: Disable CPU
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 pa
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 w
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"
Currently running DLPAR offline/online operations in a loop on a
POWER9 system with SMT=off results in the following crash:
[ 223.321032] cpu 112 (hwid 112) Ready to die...
[ 223.355963] Querying DEAD? cpu 113 (113) shows 2
[ 223.356233] cpu 114 (hwid
Hello Yangtao Li,
On Tue, Nov 20, 2018 at 07:57:31AM -0500, Yangtao Li wrote:
> use of_node_put() to release the refcount.
>
Thanks for the patch.
Reviewed-by: Gautham R. Shenoy
> Signed-off-by: Yangtao Li
> ---
> drivers/cpufreq/powernv-cpufreq.c | 17 +++--
&g
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.
> >
>
Hi Nathan,
On Tue, Sep 18, 2018 at 1:05 AM Nathan Fontenot
wrote:
>
> When performing partition migrations all present CPUs must be online
> as all present CPUs must make the H_JOIN call as part of the migration
> process. Once all present CPUs make the H_JOIN call, one CPU is returned
> to make
Hello Daniel,
On Thu, Apr 4, 2019 at 3:52 PM Daniel Lezcano wrote:
>
>
> Hi Abhishek,
>
> thanks for taking the time to test the different scenario and give us
> the numbers.
>
> On 01/04/2019 07:11, Abhishek wrote:
> >
[.. snip..]
>
> In case of POWER, this is problematic, when the
Hello Nicholas,
On Tue, Apr 2, 2019 at 4:57 PM Nicholas Piggin wrote:
>
> Using a jiffies timer creates a dependency on the tick_do_timer_cpu
> incrementing jiffies. If that CPU has locked up and jiffies is not
> incrementing, the watchdog heartbeat timer for all CPUs stops and
> creates false
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
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
er use paca to save IAMR, instead use _DAR (thanks mpe)
Looks good to me. Once we move to Nick Piggin's C-based save/restore
code, we will be saving all these SPR values on the stack anyway.
Reviewed-by: Gautham R. Shenoy
--
Thanks and Regards
gautham.
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
, the maximum time spent
> inside the loop was was 10 ms. This patch loops for 20 ms just be sure.
>
> Signed-off-by: Thiago Jung Bauermann
Thanks for this version. I have tested the patch and we no longer see
the "Querying DEAD? cpu X (Y) shows 2" message.
Tested-and-Reviewed-by: Gautham R. Shenoy
--
Thanks and Regards
gautham.
PUs stops and
> creates false positives and confusing warnings on local CPUs, and
> also causes the SMP detector to stop, so the root cause is never
> detected.
>
> Fix this by using hrtimer based timers for the watchdog heartbeat,
> like the generic kernel hardlockup detector.
>
>
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
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
e tree potentially is inconsistent.
>
> Fixes: 410bccf97881 ("powerpc/pseries: Partition migration in the kernel")
> Signed-off-by: Nathan Lynch
Audited the callbacks of of_reconfig_notify(). We are fine with
respect to CPU-Hotplug locking.
Reviewed-by: Gautham R. Shenoy
&g
ne must be blocked by callers; enforce this.
>
> Fixes: 410bccf97881 ("powerpc/pseries: Partition migration in the kernel")
> Signed-off-by: Nathan Lynch
Reviewed-by: Gautham R. Shenoy
> ---
> arch/powerpc/kernel/cacheinfo.c | 21 +
> arch/powerpc/k
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
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()
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.
From: "Gautham R. Shenoy"
During a memory hotplug operations involving resizing of the HPT, we
invoke a stop_machine() to perform the resizing. In this code path, we
end up recursively taking the cpu_hotplug_lock, first in
memory_hotplug_begin() and then subsequently in st
From: "Gautham R. Shenoy"
During a memory hotplug operations involving resizing of the HPT, we
invoke a stop_machine() to perform the resizing. In this code path, we
end up recursively taking the cpu_hotplug_lock, first in
memory_hotplug_begin() and then subsequently in st
301 - 400 of 623 matches
Mail list logo
