Which Kernel for soft realtime on ARM 9

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi all.

I'm starting a Linux project that is going to use an ARM 9 processor.

I need good soft realtime performance in that project. So I originally
planned to use Kernel 2.6.

Reading appropriate informations and comments from many sources I
learned that using 2.6 is not always advisable for small embedded
projects. The main reasons being (1) the much larger memory footprint
conflicting with the small 1st level cache and nonexisting 2nd level
cache of these processors. The most critical area for that effect was
detected to be the O(1) scheduler that uses much more code than the 2.4
O(n) scheduler, while with only some 10-20 processes the O(1) scheduler
is not faster than the O(n) version.

Moreover (2) the higher time slice scheduling rate of 1 instead of 10
msec results in unnecessarily increased overhead. In my project I will
not need fast time slices, as the running "real time" user processes all
will be triggered by hardware timers (device drivers) and don't need to
run "virtually in parallel". So I suppose they will preempt each other
according to priority and not by time slices.



So my questions are:

(1) Should I better use v2.4 with the Kernel preemption patch ?

I did some tests with that and I found that the patch does not help
much, when the IDE driver is used for a non-realtime process that runs
concurrently with a high priority realtime process. There was a max
latency of several 100 msec on a normal PC architecture. It seemed
better with network instead of IDE, but I did not do much test on that
setup and I was not clever enough to imagine other kernel stuff but file
activity that should be preempted by a high priority user process. The
embedded ARM project will not do too much IDE driver work (supposedly
not much file activity at all), so maybe the Kernel preemption patch
might do a better job here, but a compact flash drive is planned be
included and used sporadically. I would not like to see realtime
problems here. I read that the 2.6 IDE driver is completely new and much
improved. Is there a 2.4 back port of the new version ?

(2) if using 2.6, is it possible to remove the O(1) scheduler and use a
2.6 version of the O(n) scheduler ?

(3) is it possible to set the time slice scheduling rate to 10 msec in a
2.6 Kernel ?

-Michael


Re: Which Kernel for soft realtime on ARM 9
Hi Michael,
   I have an advise. Why don't you use the 2.4 kernel with the
appropriate patch and the free version of RTLinux (maybe 2.1 or 3.0).
Check out www.fsmlabs.com and www.rtlinuxfree.com for a free download.
Or even RTAI, which essentially the Free alternative to RTLinux.


Re: Which Kernel for soft realtime on ARM 9
Quoted text here. Click to load it

Why on earth would a person with only soft realtime requirements want to
massively complicate his life by bringing in RTAI ?

Wolfgang Denx wrote an article saying that 2.4 wasn't such a good
choice, but then he released his development kit for the 2.6 kernel, so
perhaps he changed his mind. An important consideration is that many
major components of the kernel which are relevant to embedded systems
are not actively supported on 2.4 - for example the MTD subsystem.


Re: Which Kernel for soft realtime on ARM 9
That is exactly what I feel:new feature will not be supported by 2.4. So
2.6 is the way to go.

But Wolfgang Denk's arguments _are_ striking: Due to the larger
footprint, The O(1) scheduler is a lot slower when there are only a few
tasks, especially if there is only a small cache and the time slice
interval is small.

So it would be really useful to have a 2.6 version of the O(n) scheduler
and define a longer time slice interval. No idea how to do this ?

-Michael

Re: Which Kernel for soft realtime on ARM 9
Quoted text here. Click to load it

I'm sure it's in sched.c/sched.h somewhere ..

With a longer time slice interval you're going to see increased latency.
I doubt this is what people want to do in an embedded environment ?


Re: Which Kernel for soft realtime on ARM 9

Quoted text here. Click to load it

Mmm, sched.c does have a minimum timeslice length parameter, although it
is always at l jiffy. I don't know what the impact might be for making
timeslices longer than jiffies ...

Re: Which Kernel for soft realtime on ARM 9
Quoted text here. Click to load it

Thanks for digging this up !

Any idea how the timeslice duration was defined in 2.4 ?

What are jiffies used for other than defining the time slice ?

The alternatives would be either define the time slice to some 10
jiffies or to define a jiffie to some 10 mSec.

I seem to remember that I once read about a parameter defining the
duration of some Kernel time constant that also was needed to use as a
factor if you want to calculate a timespan in user space based on  a
Kernel time counter readable in user space. Not sure if that was jiffies
or something else.

-Michael

Re: Which Kernel for soft realtime on ARM 9

Quoted text here. Click to load it

It doesn't seem to be so straightforward on the old 2.4 scheduler. The
timeslice length is scaled up/down depending on the value of HZ.

Quoted text here. Click to load it

Loads of things - almost anything in the kernel that requires timing.
I'd be scared to mess with it unless I really knew what I was doing.

Quoted text here. Click to load it

The value of HZ essentially defines the number of jiffies per second.

Quoted text here. Click to load it

Not sure about that one. The only portable and reliable way of dealing
with timer resolution/length is HZ, but you can cause a lot of problems
by messing with it.

Re: Which Kernel for soft realtime on ARM 9

 >
 >>
 >> Any idea how the timeslice duration was defined in 2.4 ?
 >
 >
 >
 > It doesn't seem to be so straightforward on the old 2.4 scheduler. The
 > timeslice length is scaled up/down depending on the value of HZ.
 >

That is interesting. I suppose the (default) HZ in 2.4 is 100 (and
should not be changed as the jiffie time should not be changed).

 >> What are jiffies used for other than defining the time slice ?
 >
 >
 >
 > Loads of things - almost anything in the kernel that requires timing.
 > I'd be scared to mess with it unless I really knew what I was doing.


OK.

 >
 >> The alternatives would be either define the time slice to some 10
jiffies or to define a jiffie to some 10 mSec.
 >
 >
 >
 > The value of HZ essentially defines the number of jiffies per second.


So your suggestion is that I should not try to modify the default value
if HZ.

 >
 >> I seem to remember that I once read about a parameter defining the
duration of some Kernel time constant that also was needed to use as a
factor if you want to calculate a timespan in user space based on  a
Kernel time counter readable in user space. Not sure if that was jiffies
or something else.
 >
 >
 >
 > Not sure about that one. The only portable and reliable way of dealing
 > with timer resolution/length is HZ, but you can cause a lot of problems
 > by messing with it.
 >

Right ! The constant I hand in mind _was_ Hz and thus the time counter
_was_ jiffies.

Thus, is it correct that (by default) HZ is 100 with Kernel 2.4 and 1000
with Kernel 2.6 ?

I think modifying the scheduler so that it only does time slices any n
jiffies would be worth a try.


-Michael

Re: Which Kernel for soft realtime on ARM 9
moreover, "Linux Kernel Development" by Robert Love states, that it
should be no problem modifying the HZ value (e.g. to 100 or 500 in an
x86 PC): I'm intending to use an Arm. According to Robert with this arch
HZ is 100 by default, anyway. So no problem here for me. :)

-Michael

Re: Which Kernel for soft realtime on ARM 9
"Understanding the Linux Kernel" (1st edition) talks about  the
"quantum duration" as something the minimum time  that a task is running
unless a hardware interrupts force a preemption. It seems that the
"quantum duration" can be defined when building the Kernel.

-Michael

Re: Which Kernel for soft realtime on ARM 9

Quoted text here. Click to load it

This page suggests, that it's no problem to recompile the Kernel with
another Hz value:

http://www.vmware.com/support/kb/enduser/std_adp.php?p_faqid14%20


-Michael

Re: Which Kernel for soft realtime on ARM 9
Quoted text here. Click to load it
 > I doubt this is what people want to do in an embedded environment ?
 >

In _hard_ realtime, usually time-slices can't be used anyway, as each
tasks has a dedicated maximum time to get its work done. Running one
task after the other reduces the overhead and thus the latency.

In _soft_ realtime environments this depends on the task to be done.

It is only true for tasks concurrently running without being triggered
by hardware interrupts.

In my application the critical tasks are defined to have realtime
priority and thus are not preempted by normal tasks. They are started by
an interrupt (via a Kernel driver) and after that, they are supposed to
finish (running into a read to the driver, thus again sleep, waiting for
an interrupt) as fast as possible. If multiple of these tasks are active
at the same time, it's not critical, which of them finishes first, if
not they have different priorities.

Thanks,
-Michael

Re: Which Kernel for soft realtime on ARM 9
Dont think 2.6 too seriously!
you have to do much with it!
new driver model,little improvements with complicated components


Site Timeline