Hi Eigeniy,
I am sorry for the late response. The problem is far from
trivial. I am getting snowed under many other tasks as well.
On Wed 2017-09-06 17:57:18, Eugeniy Paltsev wrote:
> Hi Petr,
>
> On Tue, 2017-09-05 at 16:54 +0200, Petr Mladek wrote:
> > On Mon 2017-08-28 19:58:07, Eugeniy Palt
Hi Vineet,
Subject contains one typo: NS48 -> HS48.
On Mon, 2017-11-06 at 11:30 -0800, Vineet Gupta wrote:
>
> HS48 cpus will have a new MMUv5, although Linux is currently not
> explicitly supporting the newer features (so remains at V4).
> The existing software/hardware version check is very ti
On 11/07/2017 07:33 AM, Alexey Brodkin wrote:
Hi Vineet,
Subject contains one typo: NS48 -> HS48.
On Mon, 2017-11-06 at 11:30 -0800, Vineet Gupta wrote:
HS48 cpus will have a new MMUv5, although Linux is currently not
explicitly supporting the newer features (so remains at V4).
The existing so
Hi,
Found these when cleaning up some old branches. The only controversial one
could be the last one.
Thx,
-Vineet
Vineet Gupta (4):
ARCv2: perf: tweak overflow interrupt
ARCv2: perf: optimize given that num counters <= 32
ARC: perf: avoid vmalloc backed mmap
ARCv2: entry: Reduce perf in
Current perf ISR loops thru all 32 counters, checking for each if it
caused the interrupt. Instead only loop thru counters which actually
interrupted (typically 1).
Signed-off-by: Vineet Gupta
---
arch/arc/kernel/perf_event.c | 24 ++--
1 file changed, 14 insertions(+), 10 de
use ffz primitive which maps to ARCv2 instruction, vs. non atomic
__test_and_set_bit
It is unlikely if we will even have more than 32 counters, but still add
a BUILD_BUG to catch that
Signed-off-by: Vineet Gupta
---
arch/arc/kernel/perf_event.c | 16 +++-
1 file changed, 7 insertion
In the more likely case of returning to kernel from perf interrupt, do a
fast path returning w/o bothering about CONFIG_PREEMPT etc
However, if returning to user space, need do go thru the usual gyrations,
as check for pending signals is an absolute must.
Signed-off-by: Vineet Gupta
---
arch/ar
For non-alising Dcache, vmalloc is not needed.
vmalloc triggers additonal D-TLB Misses in the perf interrupt code path
making it slightly inefficient as evident from hackbench runs below.
| [ARCLinux]# perf stat -e dTLB-load-misses --repeat 5 hackbench
| Running with 10*40 (== 400) tasks.
| Time: