Anders Roxell | 27 Apr 22:53 2015

[PATCHv2 0/3] Enable PREEMPT_RT_FULL on arm64

Hi,

I tested this on an arm64 juno target, and to get that to boot I
had to backport the dtb from v4.0-rc6 to v3.18.11-rt7.

Incorporated comments from Sebastian Andrzej Siewior and Ayyappa Ch.

Cheers,
Anders

Anders Roxell (3):
  arm64: Mark PMU interrupt IRQF_NO_THREAD
  arm64: Allow forced irq threading
  arch/arm64: Enable PREEMPT_RT_FULL

 arch/arm64/Kconfig                   |  2 ++
 arch/arm64/include/asm/thread_info.h |  3 +++
 arch/arm64/kernel/asm-offsets.c      |  1 +
 arch/arm64/kernel/entry.S            | 13 ++++++++++---
 arch/arm64/kernel/perf_event.c       |  2 +-
 5 files changed, 17 insertions(+), 4 deletions(-)

--

-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Clark Williams | 27 Apr 19:58 2015
Picon

Re: rt-tests, cyclictest libnuma and isolcpus

On Mon, 27 Apr 2015 17:32:22 +0200
Henning Schild <henning.schild <at> siemens.com> wrote:

> Hi,
> 
> i did not quickly find out which list to send this mail to, please cc if
> there is one.
> 
> The current cyclictest from git contains a compatibilty hack for older
> versions of libnuma, specifically the one that debian shipped. That
> hack breaks the -a option on a system that uses isolcpus. Have a look
> at src/cyclictest/rt_numa.h around line 90.
> 
> The HAVE_PARSE_CPUSTRING_ALL-case should be the default, especially now
> that even debian has a more recent version of the numa library.
> 
> Henning

I've CC'd my co-maintainer (John Kacur) and the linux-rt list, which is
where we argue^wdiscuss changes to cyclictest.

Thanks for the info, we'll look at removing the hack.

Clark
Steven Rostedt | 23 Apr 21:08 2015

[RFC][PATCH 0/4] tracing: Add new hwlat_detector tracer


This is the port of the hardware latency detector from the -rt patch
to mainline. Instead of keeping it as a device that had its own debugfs
filesystem infrastructure, it made more sense to make it into a tracer
like irqsoff and wakeup latency tracers currently are.

With this patch set, a new tracer is enabled if CONFIG_HWLAT_TRACER is
enabled. Inside the available_tracers file will be hwlat_detector.

 # cd /sys/kernel/debug/tracing
 # echo hwlat_detector > current_tracer

will enable the hwlat_detector that will create per cpu kernel threads
(which cpus is defined by the tracing/hwlat_detector/cpumask, default
 is just CPU 0).

Like the other tracers (function, function_graph, preemptirqsoff,
and mmiotracer), the hwlat_detector can add a significant performance
penalty when enabled. As each of the threads created will go into a spin
checking the trace_local_clock (sched_clock) for any gaps of time
and will report them if they are greater than the threshold defined
by tracing/tracing_thresh (usecs, default 10). The spin is performed with
interrupts disabled and runs for "width" usecs in "window" usecs time. The
width and window are defined by the values in the corresponding file
names under tracing/hwlat_detector/

To keep authorship, the first patch is the code from the -rt patch
directly, removing the setup of the device and its own ring buffer.
I made sure that it still compiles though (even though it isn't
included in the Makefile, I tested it by adding it in the Makefile
(Continue reading)

Jan Kiszka | 23 Apr 09:35 2015
Picon

[PATCH v2 RT 3.18] irq_work: Provide a soft-irq based queue

Instead of turning all irq_work requests into lazy ones on -rt, just
move their execution from hard into soft-irq context.

This resolves deadlocks of ftrace which will queue work from arbitrary
contexts, including those that have locks held that are needed for
raising a soft-irq.

Signed-off-by: Jan Kiszka <jan.kiszka <at> siemens.com>
---

Changes in v2:
 - fix execution of raised list (discovered by Mike Galbraith)
 - added comment of irq_work_run (derived from Mike's suggestion)

 kernel/irq_work.c | 34 +++++++++++++++++-----------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/kernel/irq_work.c b/kernel/irq_work.c
index 9dda38a..171dfac 100644
--- a/kernel/irq_work.c
+++ b/kernel/irq_work.c
 <at>  <at>  -85,12 +85,9  <at>  <at>  bool irq_work_queue_on(struct irq_work *work, int cpu)
 		raise_irqwork = llist_add(&work->llnode,
 					  &per_cpu(hirq_work_list, cpu));
 	else
-		raise_irqwork = llist_add(&work->llnode,
-					  &per_cpu(lazy_list, cpu));
-#else
+#endif
 		raise_irqwork = llist_add(&work->llnode,
(Continue reading)

Jiang, Yunhong | 21 Apr 19:08 2015
Picon

Should I still use pm_timer as clock source for hrt mode

Hi, all
	I noticed followed statement about TSC timer on
https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO , " Since the TSC timer on PC platforms, as
used in the previous versions, are now marked as unsuitable for hrt mode due to many lacks of
functionalities and reliabilities, you will need i.E. pm_timer as provided by ACPI to use as clock source".

	I'm testing on Intel Xeon CPU E5-2640 and has "Switched to clocksource tsc" on kernel log, I think it mean
the TSC on my system is stable and reliable enough to use as clock source, right? With the invariant and
synchronized TSC support in latest hardware, can I assume generally TSC would be better than pm_timer? 

Thanks
--jyh
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Alexandre COFFIGNAL | 20 Apr 11:35 2015

3.14.36-rt34 kernel crash on imx6

Hi All,

we are running PREEMPT_RT 3.14.36-rt34 on a imx6 board which works really fine.
But we see the following trace when we run this very simple app over ssh :

#include <stdio.h>

int main(int argc, char *argv[]){
     int i=0;
     while(1){
         printf("loop : %d\n",  i++);
     }
     return(0);
}

after a few minutes kernel crash with this message :

Does anybody have any idea on how to solve this?

Thank you very much for all help on this questions.

Regards,

Alexandre

Unable to handle kernel paging request at virtual address 3e1c7270
pgd = 80004000
[3e1c7270] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in:
(Continue reading)

Ayyappa Ch | 20 Apr 07:19 2015
Picon

Need information how to verify Linux RT Kernel latency

Hello All,

I would like to run my system regressively to verify latency of RT
Kernel. From OSADL side i got to know that only running Cyclic test is
not enough to verify RT linux latency of the system.

I got below infor from
"https://www.osadl.org/Single-View.111+M52212cb1379.0.html"

***************************************************************************************
# cyclictest -a -t -n -p99 -i100 -d50
560.44 586.11 606.12 211/1160 3727
T: 0 (18617) P:99 I:100 C:1011846111 Min:  2 Act:  4 Avg:  5 Max: 39
T: 1 (18618) P:98 I:150 C: 708641019 Min:  2 Act:  5 Avg: 11 Max: 57

The test was running on a linux-2.6.24.7-rt15 kernel in parallel with
repeated loops of "hackbench 25","ls -Ral /", and flood ping from
outside. After having executed more than one billion cyclictest loops,
the internal worst-case latency is still only 39 ┬Ás!
*******************************************************************************************

I am able to run Cyclic test . But I am not sure how to run "hackbench
25","ls -Ral /", and flood ping from outside. Can anyone help how to
run these .

Thanks and regards,
Ayyappa.Ch
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Jan Kiszka | 16 Apr 16:06 2015
Picon

[PATCH RT 3.18] ring-buffer: Mark irq_work as HARD_IRQ to prevent deadlocks

ftrace may trigger rb_wakeups while holding pi_lock which will also be
requested via trace_...->...->ring_buffer_unlock_commit->...->
irq_work_queue->raise_softirq->try_to_wake_up. This quickly causes
deadlocks when trying to use ftrace under -rt.

Resolve this by marking the ring buffer's irq_work as HARD_IRQ.

Signed-off-by: Jan Kiszka <jan.kiszka <at> siemens.com>
---

I'm not yet sure if this doesn't push work into hard-irq context that
is better not done there on -rt.

I'm also not sure if there aren't more such cases, given that -rt turns
the default irq_work wakeup policy around. But maybe we are lucky.

 kernel/trace/ring_buffer.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index f4fbbfc..6a1939e 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
 <at>  <at>  -1252,6 +1252,7  <at>  <at>  rb_allocate_cpu_buffer(struct ring_buffer *buffer, int nr_pages, int cpu)
 	init_irq_work(&cpu_buffer->irq_work.work, rb_wake_up_waiters);
 	init_waitqueue_head(&cpu_buffer->irq_work.waiters);
 	init_waitqueue_head(&cpu_buffer->irq_work.full_waiters);
+	cpu_buffer->irq_work.work.flags = IRQ_WORK_HARD_IRQ;

 	bpage = kzalloc_node(ALIGN(sizeof(*bpage), cache_line_size()),
(Continue reading)

Steven Rostedt | 15 Apr 22:04 2015

[ANNOUNCE] 3.12.40-rt55


Dear RT Folks,

I'm pleased to announce the 3.12.40-rt55 stable release.

This release is just an update to the new stable 3.12.40 version
and no RT specific changes have been made.

You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v3.12-rt
  Head SHA1: d7cf447c4d1375d53e43e5b9779910240bd09d89

Or to build 3.12.40-rt55 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.12.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.12.40.xz

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.12/patch-3.12.40-rt55.patch.xz

Enjoy,

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Steven Rostedt | 15 Apr 22:03 2015

[ANNOUNCE] 3.14.38-rt36


Dear RT Folks,

I'm pleased to announce the 3.14.38-rt36 stable release.

This release is just an update to the new stable 3.14.38 version
and no RT specific changes have been made.

You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v3.14-rt
  Head SHA1: 6e087f83a062a52a770ce319e799f37e02e1a6c4

Or to build 3.14.38-rt36 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.14.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.14.38.xz

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.14/patch-3.14.38-rt36.patch.xz

Enjoy,

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Anders Roxell | 12 Apr 09:59 2015

[PATCH] arch/arm64: Enable PREEMPT_RT_FULL

arm64 is missing support for PREEMPT_RT. The main feature which is
lacking is support for lazy preemption. The arch-specific entry code,
thread information structure definitions, and associated data tables
have to be extended to provide this support. Then the Kconfig file has
to be extended to indicate the support is available, and also to
indicate that support for full RT preemption is now available.

Signed-off-by: Anders Roxell <anders.roxell <at> linaro.org>
---

I tested this on an arm64 juno target, to get that to boot I had to
backport the dtb from v4.0-rc6 to v3.18.11-rt6.

 arch/arm64/Kconfig                   |  2 ++
 arch/arm64/include/asm/thread_info.h |  3 +++
 arch/arm64/kernel/asm-offsets.c      |  1 +
 arch/arm64/kernel/entry.S            | 14 ++++++++++----
 4 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9532f8d..62f4e00 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
 <at>  <at>  -59,7 +59,9  <at>  <at>  config ARM64
 	select HAVE_PERF_REGS
 	select HAVE_PERF_USER_STACK_DUMP
 	select HAVE_RCU_TABLE_FREE
+	select HAVE_PREEMPT_LAZY
 	select HAVE_SYSCALL_TRACEPOINTS
+	select IRQ_FORCED_THREADING
(Continue reading)


Gmane