Signed-off-by: Madhavan Srinivasan
---
Changelog v1:
Fix the event code.
arch/powerpc/perf/power9-events-list.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/perf/power9-events-list.h
b/arch/powerpc/perf/power9-events-list.h
index 929b56d47ad9..71a6bfee5c02 100644
--- a/ar
Factor out the power8 event_alternative function to share
the code with power9.
Signed-off-by: Madhavan Srinivasan
---
Changelog v1:
No changes to this patch, just a rebase
arch/powerpc/perf/isa207-common.c | 36
arch/powerpc/perf/isa207-common.h | 3 +++
a
Signed-off-by: Madhavan Srinivasan
---
Change v1:
No changes, just a rebase
arch/powerpc/perf/power9-pmu.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/powerpc/perf/power9-pmu.c b/arch/powerpc/perf/power9-pmu.c
index 7332634e18c9..b38acff8a791 100644
--- a/arch/pow
Since PM_INST_CMPL may not provide right counts in all
sampling scenarios in power9 DD1, instead use PM_INST_DISP.
Patch also update generic instruction sampling with the same.
Signed-off-by: Madhavan Srinivasan
---
Changelog v1:
Based on DD1 check, modified the event code to use for "instruction
Since PM_INST_DISP include speculative instruction,
based on the workload the dispatch count could vary
considerably. Hence as an alternative, for completed
instruction counting, program the PM_INST_DISP event
to the MMCR* but use Instruction Counter register value.
Signed-off-by: Madhavan Sriniva
PMC5 on POWER9 DD1 may not provide right counts in all
sampling scenarios, hence use PM_INST_DISP event instead
in PMC2 or PMC3 in preference.
Signed-off-by: Madhavan Srinivasan
---
Changelog v1:
No changes, just a rebase
arch/powerpc/perf/isa207-common.h | 4
arch/powerpc/perf/power9-pmu.
In Power9, L2/L3 bus events are always available as a
"bank" of 4 events. To obtain the counts for any of the
l2/l3 bus events in a given bank, the user will have to
program PMC4 with corresponding l2/l3 bus event for that
bank. Patch add a mask and a new pass to updates the mask
for each PMU used
On Fri, 2017-02-10 at 08:48 +0100, Christophe LEROY wrote:
>
> Le 10/02/2017 à 06:31, Cyril Bur a écrit :
> > A bug in the -02 optimisation of GCC 5.4 6.1 and 6.2 causes
> > setup_command_line() to not pass the correct first argument to strcpy
> > and therefore not actually copy the command_line.
Vipin K Parashar writes:
> OPAL returns OPAL_WRONG_STATE for XSCOM operations
>
> done to read any core FIR which is sleeping, offline.
OK.
Do we know why Linux is causing that to happen?
It's also returned from many of the XIVE routines if we're in the wrong
xive mode, all of which would indi
A bug in the -02 optimisation of GCC 5.4 6.1 and 6.2 causes
setup_command_line() to not pass the correct first argument to strcpy
and therefore not actually copy the command_line.
A workaround patch was proposed: http://patchwork.ozlabs.org/patch/673130/
some discussion ensued.
A GCC bug was rais
This patch series increase the effective virtual address range of
applications from 64TB to 128TB. We do that by supporting a
68 bit virtual address. On platforms that can only do 65 bit virtual
address we limit the max contexts to a 16bit value instead of 19.
The patch series also switch the pag
In followup patch we want to increase the va range which will result
in us requiring high_slices to have more than 64 bits. To enable this
convert high_slices to bitmap. We keep the number bits same in this patch
and later change that to higher value
Signed-off-by: Aneesh Kumar K.V
---
arch/powe
This avoid copying the slice_mask struct as function return value
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/slice.c | 63 +++--
1 file changed, 29 insertions(+), 34 deletions(-)
diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
With current kernel, we use the top 4 context for the kernel. Kernel VSIDs are
built
using these top context values and effective segemnt ID. In the following
patches,
we want to increase the max effective address to 512TB. We achieve that by
increasing the effective segments IDs there by increas
Inorder to support large effective address range (512TB), we want to increase
the virtual address bits to 68. But we do have platforms like p4 and p5 that can
only do 65 bit VA. We support those platforms by limiting context bits on them
to 16.
The protovsid -> vsid conversion is verified to work
We will be updating this later to use struct mm_struct. Move this so that
function
finds the definition of struct mm_struct;
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/paca.h | 18 +-
arch/powerpc/kernel/paca.c | 19 +++
arch/powerpc/mm/has
We update the hash linux page table layout such that we can support 512TB. But
we limit the TASK_SIZE to 128TB. We can switch to 128TB by default without
conditional because that is the max virtual address supported by other
architectures. We will later add a mechanism to on-demand increase the
app
The check against VSID range is implied when we check task size against
hash and radix pgtable range[1], because we make sure page table range cannot
exceed vsid range.
[1] BUILD_BUG_ON(TASK_SIZE_USER64 > H_PGTABLE_RANGE);
BUILD_BUG_ON(TASK_SIZE_USER64 > RADIX_PGTABLE_RANGE);
The check for smalle
Once xmon is triggered, there is no interface to turn it off again.
However there exists disable/enable xmon code flows. And more important,
System reset interrupt on powerVM will fire an oops to make a dump. At
that time, xmon should not be triggered.
So add 'z' option after current 'x|X' exit co
Hi Micheal,
Can you please look at this patchset?
-Mukesh
On Tuesday 06 December 2016 12:07 PM, Mukesh Ojha wrote:
Hi Michael,
Can you please have a look at this patchset as there is no
functional changes involve with this?
Thanks,
Mukesh
On Thursday 01 December 2016 02:38 PM, Mukesh O
20 matches
Mail list logo
