[PATCH] powerpc: mitigate impact of decrementer reset

The POWER ISA defines an always-running decrementer which can be used to schedule interrupts after a certain time interval has elapsed. The decrementer counts down at the same frequency as the Time Base, which is 512 MHz. The maximum value of the decrementer is 0x7fff. This works out to a

Re: [PATCH] powerpc: mitigate impact of decrementer reset

On 10/08/2014 12:37 AM, Heinz Wrobel wrote: what if your tb wraps during the test? Per the Power ISA, Time Base is 64 bits, monotonically increasing, and is writable only in hypervisor state. To my understanding, it is set to zero at boot (although this is not prescribed). Also, as noted

Re: powerpc: mitigate impact of decrementer reset

Sorry it took me so long to get back to this... On 10/07/2014 09:52 PM, Michael Ellerman wrote: On Tue, 2014-07-10 at 19:13:24 UTC, Paul Clarke wrote: The POWER ISA defines an always-running decrementer which can be used to schedule interrupts after a certain time interval has elapsed

Re: [PATCH] powerpc: mitigate impact of decrementer reset

On 11/10/2014 04:08 AM, Benjamin Herrenschmidt wrote: On Tue, 2014-10-07 at 14:13 -0500, Paul Clarke wrote: The POWER ISA defines an always-running decrementer which can be used to schedule interrupts after a certain time interval has elapsed. The decrementer counts down at the same frequency

Re: [PATCH] powerpc/powernv: Support OPAL requested heartbeat

On 11/12/2014 12:03 AM, Benjamin Herrenschmidt wrote: If OPAL requests it, call it back via opal_poll_events() at a regular interval. Some versions of OPAL on some machines require this to operate some internal timeouts properly. I don't see any reason why not, but wanted to ask to make sure:

Re: powerpc: mitigate impact of decrementer reset

On 11/12/2014 08:39 PM, Michael Ellerman wrote: On Wed, 2014-11-05 at 11:06 -0600, Paul Clarke wrote: On 10/07/2014 09:52 PM, Michael Ellerman wrote: On Tue, 2014-07-10 at 19:13:24 UTC, Paul Clarke wrote: This patch short-circuits the reset of the decrementer, exiting after the decrementer

Re: [PATCH] powerpc: Reword the returning from prom_init message

On 01/12/2015 03:48 AM, Michael Ellerman wrote: We get way too many bug reports that say the kernel is hung in prom_init, which stems from the fact that the last piece of output people see is returning from prom_init. The kernel is almost never hung in prom_init(), it's just that it's crashed

[PATCH] powerpc: re-enable dynticks

/* _ASM_IRQ_WORK_H */ -- Regards, Paul Clarke, IBM ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2] powerpc: re-enable dynticks

It appears the discussion wrapped up on this, favorably. Is there anything else I need to do to get this merged? Regards, PC On 02/20/2015 11:18 PM, Paul E. McKenney wrote: On Fri, Feb 20, 2015 at 11:13:33AM -0600, Paul Clarke wrote: implement arch_irq_work_has_interrupt() for powerpc

[PATCH v2] powerpc: re-enable dynticks

implement arch_irq_work_has_interrupt() for powerpc Commit 9b01f5bf3 introduced a dependency on IRQ work self-IPIs for full dynamic ticks to be enabled, by expecting architectures to implement a suitable arch_irq_work_has_interrupt() routine. Several arches have implemented this routine,

[PATCH v2] powerpc: re-enable dynticks

implement arch_irq_work_has_interrupt() for powerpc (resending because I messed up the e-mail addresses) Commit 9b01f5bf3 introduced a dependency on IRQ work self-IPIs for full dynamic ticks to be enabled, by expecting architectures to implement a suitable arch_irq_work_has_interrupt()

Re: [PATCH] cpufreq: powernv: Redesign the presentation of throttle notification

On 12/13/2015 12:17 PM, Shilpasri G Bhat wrote: Replace the throttling event console messages to perf trace event "power:powernv_throttle" and throttle counter stats which are exported in sysfs. The newly added sysfs files are as follows: 1)/sys/devices/system/node/node0/throttle_frequencies

Re: [PATCH 2/2] powerpc/pseries: Dynamically increase RMA size

Only nits from me...(see below) On 08/05/2016 01:30 PM, Sukadev Bhattiprolu wrote: Here is an updated patch to fix the build when CONFIG_PPC_PSERIES=n. --- From d4f77a6ca7b6ea83f6588e7d541cc70bf001ae85 Mon Sep 17 00:00:00 2001 From: root Date: Thu, 4 Aug 2016

Re: [PATCH 9/9] powerpc: A new cache geometry aux vectors

On 01/08/2017 05:31 PM, Benjamin Herrenschmidt wrote: This adds AUX vectors for the L1I,D, L2 and L3 cache levels providing for each cache level the size of the cache in bytes and the geometry (line size and number of ways). We chose to not use the existing alpha/sh definition which packs all

Re: [PATCH v4 3/7] kprobes: validate the symbol name provided during probe registration

a nit or two, below... On 04/21/2017 07:32 AM, Naveen N. Rao wrote: > diff --git a/kernel/kprobes.c b/kernel/kprobes.c > index 6a128f3a7ed1..ff9b1ac72a38 100644 > --- a/kernel/kprobes.c > +++ b/kernel/kprobes.c > @@ -1383,6 +1383,34 @@ bool within_kprobe_blacklist(unsigned long addr) > } > >

Re: [PATCH v4 4/7] powerpc/kprobes: Use safer string functions in kprobe_lookup_name()

On 04/21/2017 08:33 AM, Paul Clarke wrote: > On 04/21/2017 07:33 AM, Naveen N. Rao wrote: >> } else if (name[0] != '.') { >> dot_name[0] = '.'; >> dot_name[1] = '\0'; >> -strncat(dot_name, name, KSYM_NAME_LEN - 2); >> +

Re: [PATCH v4 4/7] powerpc/kprobes: Use safer string functions in kprobe_lookup_name()

On 04/21/2017 07:33 AM, Naveen N. Rao wrote: > Convert usage of strchr()/strncpy()/strncat() to > strnchr()/memcpy()/strlcat() for simpler and safer string manipulation. > > Reported-by: David Laight > Signed-off-by: Naveen N. Rao > ---

Re: [PATCH v4 4/7] powerpc/kprobes: Use safer string functions in kprobe_lookup_name()

Sent too soon. The suggestions don't guarantee null termination. Refined, below. (Sorry for the noise.) On 04/21/2017 08:33 AM, Paul Clarke wrote: > On 04/21/2017 07:33 AM, Naveen N. Rao wrote: >> Convert usage of strchr()/strncpy()/strncat() to >> strnchr()/memcpy()/strlca

Re: [PATCH v2] powerpc: A new cache geometry aux vectors

On 03/02/2017 10:01 PM, Michael Ellerman wrote: Paul Clarke <p...@us.ibm.com> writes: On 03/02/2017 12:33 AM, Michael Ellerman wrote: Paul Clarke <p...@us.ibm.com> writes: On 02/02/2017 12:22 AM, Benjamin Herrenschmidt wrote: This adds AUX vectors for the L1I,D, L2 and L3

Re: [PATCH v2] powerpc: A new cache geometry aux vectors

On 02/02/2017 12:22 AM, Benjamin Herrenschmidt wrote: This adds AUX vectors for the L1I,D, L2 and L3 cache levels providing for each cache level the size of the cache in bytes and the geometry (line size and number of ways). We chose to not use the existing alpha/sh definition which packs all

Re: [PATCH v2] powerpc: A new cache geometry aux vectors

On 03/02/2017 12:33 AM, Michael Ellerman wrote: Paul Clarke <p...@us.ibm.com> writes: On 02/02/2017 12:22 AM, Benjamin Herrenschmidt wrote: This adds AUX vectors for the L1I,D, L2 and L3 cache levels providing for each cache level the size of the cache in bytes and the geometry (lin

Re: [PATCH V4] powerpc/hugetlb: Add ABI defines for supported HugeTLB page sizes

nits... take 'em or leave 'em... On 04/07/2017 08:01 AM, Michael Ellerman wrote: Anshuman Khandual writes: And I reworded the comment the make it clearer (I think) that most users shouldn't need to use these, and should just use the default size: /* * When

Re: [PATCH] perf/python: Add ppc64le to audit uname list

Coincidentally, I just saw a developer stumble upon this within the last week. Could this be pushed upstream soon? PC On 08/02/2017 10:06 AM, Arnaldo Carvalho de Melo wrote: > Em Wed, Aug 02, 2017 at 08:12:16PM +0530, Naveen N. Rao escreveu: >> Before patch: >> $ uname -m >> ppc64le > >

Re: [PATCH] powerpc/64s: dt_cpu_ftrs boot time setup option

On 05/11/2017 10:46 PM, Michael Ellerman wrote: > Paul Clarke <p...@us.ibm.com> writes: >> On 05/11/2017 06:24 AM, Nicholas Piggin wrote: >>> Provide a dt_cpu_ftrs= cmdline option to disable the dt_cpu_ftrs CPU >>> feature discovery, and fall back to the "cp

Re: [PATCH] powerpc/64s: dt_cpu_ftrs boot time setup option

On 05/11/2017 06:24 AM, Nicholas Piggin wrote: > Provide a dt_cpu_ftrs= cmdline option to disable the dt_cpu_ftrs CPU > feature discovery, and fall back to the "cputable" based version. This boat has already sailed, I think, but "ftrs"? Was it too difficult to type "features"? This seems like

Re: [PATCH] powerpc/lib: Split xor_vmx file to guarantee instruction ordering

On 05/23/2017 06:45 PM, Matt Brown wrote: > The xor_vmx.c file is used for the RAID5 xor operations. In these functions > altivec is enabled to run the operation and then disabled. However due to > compiler instruction reordering, altivec instructions are being run before > enable_altivec() and

Re: [PATCH] powerpc/lib: Split xor_vmx file to guarantee instruction ordering

On 05/24/2017 11:56 PM, Matt Brown wrote: > On Wed, May 24, 2017 at 11:36 PM, Paul Clarke <p...@us.ibm.com> wrote: >> On 05/23/2017 06:45 PM, Matt Brown wrote: >>> The xor_vmx.c file is used for the RAID5 xor operations. In these functions >>> altive

Re: [PATCH v2] powerpc/kprobes: refactor kprobe_lookup_name for safer string operations

On 05/04/2017 05:24 AM, Naveen N. Rao wrote: > Use safer string manipulation functions when dealing with a > user-provided string in kprobe_lookup_name(). > > Reported-by: David Laight > Signed-off-by: Naveen N. Rao > --- > Changed to

Re: [PATCH] selftests/powerpc: Fix strncpy usage

On 06/22/2018 09:43 AM, Breno Leitao wrote: > If you don't mind, I would solve this problem slightly different, as it seems > to be more readable. > > - strncpy(prog, argv[0], strlen(argv[0])); > + if (strlen(argv[0]) >= LEN_MAX){ > + fprintf(stderr, "Very big executable

[PATCH 3/4] [powerpc] perf vendor events: Add JSON metrics for POWER9

Descriptions of metrics for POWER9 processors can be found in the "POWER9 Performance Monitor Unit User’s Guide", which is currently available on the "IBM Portal for OpenPOWER" (https://www-355.ibm.com/systems/power/openpower/welcome.xhtml) at

[PATCH 2/4] [powerpc] perf vendor events: Add JSON metrics for POWER9

Descriptions of metrics for POWER9 processors can be found in the "POWER9 Performance Monitor Unit User’s Guide", which is currently available on the "IBM Portal for OpenPOWER" (https://www-355.ibm.com/systems/power/openpower/welcome.xhtml) at

[PATCH 4/4] [powerpc] perf vendor events: Add JSON metrics for POWER9

Descriptions of metrics for POWER9 processors can be found in the "POWER9 Performance Monitor Unit User’s Guide", which is currently available on the "IBM Portal for OpenPOWER" (https://www-355.ibm.com/systems/power/openpower/welcome.xhtml) at

[PATCH 1/4] [powerpc] perf vendor events: Add JSON metrics for POWER9

Descriptions of metrics for POWER9 processors can be found in the "POWER9 Performance Monitor Unit User’s Guide", which is currently available on the "IBM Portal for OpenPOWER" (https://www-355.ibm.com/systems/power/openpower/welcome.xhtml) at

[PATCH v2 0/4] [powerpc] perf vendor events: Add JSON metrics for POWER9

[Note this is for POWER*9* and is different content than a previous patchset for POWER*8*.] The patches define metrics and metric groups for computation by "perf" for POWER9 processors. Paul Clarke (4): [powerpc] perf vendor events: Add JSON metrics for POWER9 [powerpc] perf ven

Re: sys_exit: NR -1

On 6/12/19 1:32 AM, Naveen N. Rao wrote: > Paul Clarke wrote: >> What are the circumstances in which raw_syscalls:sys_exit reports "-1" for >> the syscall ID? >> >>     perf  5375 [007] 59632.478528:   raw_syscalls:sys_enter: NR 1 (3, >> 9fb888, 8

Re: sys_exit: NR -1

On 6/13/19 4:00 PM, Paul Clarke wrote: > On 6/12/19 1:32 AM, Naveen N. Rao wrote: >> Paul Clarke wrote: >>> What are the circumstances in which raw_syscalls:sys_exit reports "-1" for >>> the syscall ID? >>> >>>     perf  5375 [007] 59632.47

sys_exit: NR 0 (was "sys_exit: NR -1")

I'm seeing another asymmetry, this one is on powerpc: -- perf 30179 [001] 10374622.667436: raw_syscalls:sys_enter: NR 11 (3fffe16ef55e, [...]) ls 30179 [002] 10374622.667921: raw_syscalls:sys_exit: NR 0 = 0 -- Syscall "11" is "execve", but is it expected that the sys_exit will report the

Re: [RFC] powerpc/pseries/hcall: remove the save/restore of CR

On 9/26/19 10:48 PM, Lijun Pan wrote: > According to the PAPR, hcalls should not modify the Condition > Register fields, hence save/restore the CR is not necessary. Just curious: could you provide a more specific reference? PC

Re: [RFC 00/11] perf: Enhancing perf to export processor hazard information

On 3/1/20 11:23 PM, Ravi Bangoria wrote: > Most modern microprocessors employ complex instruction execution > pipelines such that many instructions can be 'in flight' at any > given point in time. Various factors affect this pipeline and > hazards are the primary among them. Different types of