On Fri, Jul 24, 2015 at 05:28:40PM -0400, Eric B Munson wrote:
> With the refactored mlock code, introduce a new system call for mlock.
> The new call will allow the user to specify what lock states are being
> added. mlock2 is trivial at the moment, but a follow on patch will add
> a new mlock st
Samuel Mendoza-Jonas writes:
> Always include a timeout when waiting for secondary cpus to enter OPAL
> in the kexec path, rather than only when crashing.
This *sounds* reasonable... but I wonder what actual worse case could
be and why we'd get stuck too long waiting for things?
What was the ori
Peter Zijlstra [pet...@infradead.org] wrote:
| On Tue, Jul 14, 2015 at 08:01:52PM -0700, Sukadev Bhattiprolu wrote:
| > Move the part of perf_event_read_value() that computes the event
| > counts and event times into a new function, perf_event_compute().
| >
| > This would allow us to call perf_ev
On Mon, 27 Jul 2015, Michael Schmitz wrote:
> Finn,
>
> my bad - there is indeed a change in the /proc/driver/nvram output:
>
> --- nvram-4.out2015-07-24 12:32:44.0 +1200
> +++ nvram-4p2.out2015-07-27 13:56:06.0 +1200
> @@ -7,7 +7,7 @@
> Keyboard language: English (US)
The 24x7 counters in Powerpc allow monitoring a large number of counters
simultaneously. They also allow reading several counters in a single
HCALL so we can get a more consistent snapshot of the system.
Use the PMU's transaction interface to monitor and read several event
counters at once. The id
Define a new PERF_PMU_TXN_READ interface to read a group of counters
at once.
pmu->start_txn()// Initialize before first event
for each event in group
pmu->read(event); // Queue each event to be read
pmu->commit_txn() //
Add a return value to __perf_event_read(). The return value will be
needed later in perf_read_group() implements ability to read several
counters in a PERF_PMU_TXN_READ transaction.
Signed-off-by: Sukadev Bhattiprolu
---
kernel/events/core.c | 22 +++---
1 file changed, 19 inse
Add a 'group' parameter to perf_event_read(). It will be used (set
to true) in a follow-on patch to update event times of the group.
Signed-off-by: Sukadev Bhattiprolu
---
kernel/events/core.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/kernel/events/
Add a return value to perf_event_read(). The return value will be
needed later in perf_read_group() implements ability to read several
counters in a PERF_PMU_TXN_READ transaction.
Signed-off-by: Sukadev Bhattiprolu
---
kernel/events/core.c | 19 +--
1 file changed, 13 insertion
Unroll the calls to perf_event_read_value() in perf_read_group()
so we can later optimize out parts we don't need for group events.
Signed-off-by: Sukadev Bhattiprolu
---
kernel/events/core.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/kernel/events/c
Move the part of perf_event_read_value() that aggregates the event
counts and event times into a new function, perf_event_aggregate().
This would allow us to call perf_event_aggregate() independently.
Signed-off-by: Sukadev Bhattiprolu
---
Changelog[v4]
[Peter Zijlstra] Add missing lockd
From: "Peter Zijlstra (Intel)"
In order to free up the perf_event_read_group() name:
s/perf_event_read_\(one\|group\)/perf_read_\1/g
s/perf_read_hw/__perf_read/g
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/events/core.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletion
perf_event_read() does two things:
- call the PMU to read/update the counter value, and
- compute the total count of the event and its children
Not all callers need both. perf_event_reset() for instance needs the
first piece but doesn't need the second. Similarly, when we impleme
Unlike normal hardware PMCs, the 24x7 counters in Power8 are stored in
memory and accessed via a hypervisor call (HCALL). A major aspect of the
HCALL is that it allows retireving _several_ counters at once (unlike
regular PMCs, which are read one at a time). By reading several counters
at once, we
Currently, the PMU interface allows reading only one counter at a time.
But some PMUs like the 24x7 counters in Power, support reading several
counters at once. To leveage this functionality, extend the transaction
interface to support a "transaction type".
The first type, PERF_PMU_TXN_ADD, refers
On Tue, 2015-30-06 at 08:20:29 UTC, Anshuman Khandual wrote:
> The commit 69111bac42f5ce ("powerpc: Replace __get_cpu_var uses")
> replaced all usage of get_cpu_var with this_cpu_ptr inside core
> perf event handling on powerpc. But it skipped one of them which
> is being replaced with this patch.
From: "David A. Long"
Several architectures have identical or functionally equivalent code
implementing parts of the HAVE_REGS_AND_STACK_ACCESS_API feature. Move
that code out of the architecture directories.
Signed-off-by: David A. Long
---
arch/arm/include/asm/ptrace.h | 6 ---
ar
From: "David A. Long"
The pt_regs_offset structure is used for the HAVE_REGS_AND_STACK_ACCESS_API
feature and has identical definitions in four different arch ptrace.h
include files. It seems unlikely that definition would ever need to be
changed regardless of architecture so lets move it into
in
From: "David A. Long"
Move duplicate and functionally equivalent code for accessing registers
and stack (CONFIG_HAVE_REGS_AND_STACK_ACCESS_API) from arch subdirs into
common kernel files.
Changes since v1:
Move the REG_OFFSET_NAME and REG_OFFSET_END macros to architecture-
independent in
On Tue, 2015-30-06 at 08:20:27 UTC, Anshuman Khandual wrote:
> BHRB (Branch History Rolling Buffer) is a rolling buffer. Hence we
> might end up in a situation where we have read one target address
> but when we try to read the next entry indicating the from address
> of the target address, the buf
On 07/27/2015 03:11 AM, Jacek Anaszewski wrote:
> Hi Vasant,
>
Hi Jacek,
> Two trivial details left. Please find them below.
Thanks for the review/Ack. I'll fix below issues and resend patchset.
I will ask Benh/Michael to take this patchset. But this patchset is depending
on your core changes.
Finn,
my bad - there is indeed a change in the /proc/driver/nvram output:
--- nvram-4.out2015-07-24 12:32:44.0 +1200
+++ nvram-4p2.out2015-07-27 13:56:06.0 +1200
@@ -7,7 +7,7 @@
Keyboard language: English (US)
Date format : DD.MM.YY, 24h clock
Boot delay : 32
From: Madalin-Cristian Bucur
Date: Fri, 24 Jul 2015 15:49:39 +
>> -Original Message-
>> From: Joe Perches [mailto:j...@perches.com]
>> On Wed, 2015-07-22 at 19:16 +0300, Madalin Bucur wrote:
>> > Allow the user to tweak the refill threshold and the total number
>> > of buffers in the
Hi,
Reviewed-by: Daniel Axtens
FWIW, Ian is on leave for 2 weeks and Mikey for 1 week. However, as one
of the other CXL developers I'm very happy for this patch to go in.
Regards,
Daniel
On Mon, 2015-07-27 at 00:18 +0300, Vladimir Zapolskiy wrote:
> The sanity checks for overflow are not neede
Hi Vasant,
Two trivial details left. Please find them below.
Since for two next weeks I will be unable even to compile-test
this patch set I propose to merge it via powerpc tree.
Having both mentioned issues addressed, for this patch:
Acked-by: Jacek Anaszewski
On 25.07.2015 07:21, Vasant He
This change removes a number of redundant checks on bin attribute
client's side, the same checks are done by sysfs_kf_bin_read() or
sysfs_kf_bin_write() caller from fs/sysfs/file.c.
Note, drivers/misc/pch_phub.c and drivers/misc/c2port/core.c may be
updated in a similar way, however this task is n
The sanity checks for overflow are not needed, because this is done on
caller side in fs/sysfs/file.c
Signed-off-by: Vladimir Zapolskiy
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Ian Munsie
Cc: Michael Neuling
---
drivers/misc/cxl/sysfs.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
27 matches
Mail list logo
