Fwd: Re: preempt-rt amd uClibc

Fwd: Re: preempt-rt amd uClibc

[Johannes Bauer]

Thats good news, thank you Remy!

I was able to run cyclictest
\\\"cyclictest -t1 -p 80 -n -i 10000 -l 1000\\\" an thw maximum latencies were about
650us. However the intervall timers \\\"cyclictest -t1 -p 80 -i 10000 -l 1000\\\"
result in abou 3000us maximum latencies.
Is it common that interval timers have higher latencies and could this values be
reasonable for a 72MHz arm7tdmi (ARMv4T).

Anyone has any values to compare or can tell me if those values are reasonable?

Kind Regards
Johannes Bauer

----- Original von:  Remy Bohmer

> Hi,

2011/4/15 Johannes Bauer <hannes_bauer@aon.at>:
> Hi everybody!
>
> I downloaded the newest uClinux dist a while ago and compiled it with 2.6.33
kernel and the 2.6.33.7.2-rt30 patch applied.
> Then i by hand implemeted an old patch for arm lpc22xx machine (ARMv4T), since
i am running a lpc2478 board from embedded artists.
> I had to implement a clockevent/source timer to add hrtimer support. I
compiled it all with uClibc since it as a NOMMU system.
>
> Now i have some questions:
> Is it possible to run the preempt-rt patch with the uClinux distribution and
uClibc?

The preempt-RT patch runs just fine with a uClibc userspace, I have no
idea what it will do in a NOMMU system (never tried it)

> I read a few times that if doesnt support PI mutexes, but arent those RT
mutexes part of the kernel?

The kernel itself has PI-mutexes support, _internally_within_ the
kernel; regardless what type of userspace C-library is being used.
However, for _userspace_ PI-mutexes, you will need a C-library that
supports it (search for example for PTHREAD_PRIO_INHERIT in the
library code). 2 options:
* Glibc since version 2.5 (actually 2.4.90 and higher)
* uClibc master. You might have some luck since there is now NPTL
support in uClibc master. So, get the master tree of uClibc and see if
it works for you.
(http://git.uclibc.org/uClibc/snapshot/uClibc-master.tar.gz)
I have not tested it myself though, but if it works, please share the
good news.

Have Fun!

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



----- Ende der weitergeleiteten Nachricht -----

Re: Fwd: Re: preempt-rt amd uClibc

[Patrice Kadionik]

Le 20/04/2011 12:47, Johannes Bauer a écrit :
> Thats good news, thank you Remy!
Hi Johannes,

> I was able to run cyclictest
Great news!
Can you post your latest hrtimer port for your HW? It could be useful 
for anyone who will want to do the same thing in the future...
> \\\"cyclictest -t1 -p 80 -n -i 10000 -l 1000\\\" an thw maximum latencies were about
> 650us. However the intervall timers \\\"cyclictest -t1 -p 80 -i 10000 -l 1000\\\"
> result in abou 3000us maximum latencies.
> Is it common that interval timers have higher latencies and could this values be
> reasonable for a 72MHz arm7tdmi (ARMv4T).
You may read this paper (page 2) from OSADL: 
https://www.osadl.org/fileadmin/dam/press/Industrial-Ethernet-Book-2009-05.pdf
It gives an empirical law for max latency under PREEMPT-RT:
"A number of commercially available Linux distributions (e.g. Red Hat’s 
MRG) already contain the PREEMPT_RT patches in production quality. The 
worst-case rule-of-thumb latency is in the range of 10^5 multiplied by 
the CPU cycle duration with these systems without special optimisation. 
For example, a 1GHz processor has a cycle duration of one nanosecond 
which results in a worst-case latency of about 100μs. This is considered 
sufficient for the vast majority of real-time projects. Using latency 
optimisation, however, the worst-case latency can be reduced by up to 
three times."

For a 72 MHz CPU clock, it gives: 1388 µs
I've done a PREEMPT-RT port for NIOS 2 with MMU (with hrtimer port too). 
With cyclictest, I've measured for a low performance design with 50 MHz 
NIOS 2 HW a latency up to 1400 µs and for another more powerful design 
with 125 MHz NIOS 2 HW a latency up to 650 µs.

Your 650 µs value sounds reasonable.

Cheers;

Pat.
> Anyone has any values to compare or can tell me if those values are reasonable?
>
> Kind Regards
> Johannes Bauer
>
> ----- Original von:  Remy Bohmer
>
>> Hi,
> 2011/4/15 Johannes Bauer<hannes_bauer@aon.at>:
>> Hi everybody!
>>
>> I downloaded the newest uClinux dist a while ago and compiled it with 2.6.33
> kernel and the 2.6.33.7.2-rt30 patch applied.
>> Then i by hand implemeted an old patch for arm lpc22xx machine (ARMv4T), since
> i am running a lpc2478 board from embedded artists.
>> I had to implement a clockevent/source timer to add hrtimer support. I
> compiled it all with uClibc since it as a NOMMU system.
>> Now i have some questions:
>> Is it possible to run the preempt-rt patch with the uClinux distribution and
> uClibc?
>
> The preempt-RT patch runs just fine with a uClibc userspace, I have no
> idea what it will do in a NOMMU system (never tried it)
>
>> I read a few times that if doesnt support PI mutexes, but arent those RT
> mutexes part of the kernel?
>
> The kernel itself has PI-mutexes support, _internally_within_ the
> kernel; regardless what type of userspace C-library is being used.
> However, for _userspace_ PI-mutexes, you will need a C-library that
> supports it (search for example for PTHREAD_PRIO_INHERIT in the
> library code). 2 options:
> * Glibc since version 2.5 (actually 2.4.90 and higher)
> * uClibc master. You might have some luck since there is now NPTL
> support in uClibc master. So, get the master tree of uClibc and see if
> it works for you.
> (http://git.uclibc.org/uClibc/snapshot/uClibc-master.tar.gz)
> I have not tested it myself though, but if it works, please share the
> good news.
>
> Have Fun!
>
> Remy
> --
> To unsubscribe from this list: send the line \\\"unsubscribe linux-rt-users\\\" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> ----- Ende der weitergeleiteten Nachricht -----
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Patrice Kadionik. F6KQH / F4CUQ
-----------

+----------------------------------------------------------------------+
+"Tout doit etre aussi simple que possible, pas seulement plus simple" +
+----------------------------------------------------------------------+
+ Patrice Kadionik             http://www.enseirb-matmeca.fr/~kadionik +
+ IMS Laboratory               http://www.ims-bordeaux.fr/             +
+ ENSEIRB-MATMECA              http://www.enseirb-matmeca.fr           +
+ PO BOX 99                    fax   : +33 5.56.37.20.23               +
+ 33402 TALENCE Cedex          voice : +33 5.56.84.23.47               +
+ FRANCE                       mailto:patrice.kadionik@ims-bordeaux.fr +
+----------------------------------------------------------------------+

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

sched_clock for arm

[Johannes Bauer]

Hello everybody!

Again i am a little bit confused - sorry!

For the lpc2478 board (arm7tdmi-s), with Patrice Kadionik\'s help, I implemented a clocksource and clock event source to achieve hrtimer resolution. I realised i have to implement a sched_clock function too, in order to achieve better scheduling resolution. I took some examples from the arch/arm directory, where totally different solution exist. Very few using a cnt32_to_63() functions, others only clocksource_cyc2ns().
Is it ok to implement a sched_clock with only clocksource_cyc2ns() with a 72MHz 32bit counter, since it wraps somehow often?
It seems the newest preempt-release announced by Thomas Gleixner a few weeks ago has a new arm sched_clock support provided by Russel King, but I am using 2.6.33.7.2-rt30, where those features are not built in and i cannot update the kernel yet
I found a conversation initiated by Johannes Stezenbach (http://ns.spinics.net/lists/arm-kernel/msg86383.html) having the same toopic, but actually no specific answer to that question was posted.

So is it enough to use clocksource_cyc2ns(), or do I have use something else, and if yould you please point out some code that does exactly what needs to be done for arm architecture.

At the moment my implemetations looks as following:

   unsigned long long notrace sched_clock(void)
   {
   return clocksource_cyc2ns(pit_clk.read(&pit_clk),pit_clk.mult,pit_clk.shift);
   }

I would post the code as example here in order to give people a better 

Thank you again and kind regards
Johannes Bauer

Re: sched_clock for arm

[Johannes Bauer]

Does nobody have any idea about that topic?

At the moment im using that implementation and it seems to work unless i am using cyclcitest with -i < 1000.
However when i \"cat /proc/timer_list\" i sometimes get \"active timers\" that expire before \"next_event\", which seems somhow odd to me. The difference in that values is about 1 ms which should be easily be able to handle by the highres timer...

> Hello everybody!

Again i am a little bit confused - sorry!

For the lpc2478 board (arm7tdmi-s), with Patrice Kadionik\\\'s help, I implemented a clocksource and clock event source to achieve hrtimer resolution. I realised i have to implement a sched_clock function too, in order to achieve better scheduling resolution. I took some examples from the arch/arm directory, where totally different solution exist. Very few using a cnt32_to_63() functions, others only clocksource_cyc2ns().
Is it ok to implement a sched_clock with only clocksource_cyc2ns() with a 72MHz 32bit counter, since it wraps somehow often?
It seems the newest preempt-release announced by Thomas Gleixner a few weeks ago has a new arm sched_clock support provided by Russel King, but I am using 2.6.33.7.2-rt30, where those features are not built in and i cannot update the kernel yet
I found a conversation initiated by Johannes Stezenbach (http://ns.spinics.net/lists/arm-kernel/msg86383.html) having the same toopic, but actually no specific answer to that question was posted.

So is it enough to use clocksource_cyc2ns(), or do I have use something else, and if yould you please point out some code that does exactly what needs to be done for arm architecture.

At the moment my implemetations looks as following:

   unsigned long long notrace sched_clock(void)
   {
   return clocksource_cyc2ns(pit_clk.read(&pit_clk),pit_clk.mult,pit_clk.shift);
   }

I would post the code as example here in order to give people a better 

Thank you again and kind regards
Johannes Bauer
--
To unsubscribe from this list: send the line \"unsubscribe linux-rt-users\" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html