1. Home
  2. Embedded Linux
  3. Which Kernel for soft realtime on ARM 9

Which Kernel for soft realtime on ARM 9

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

Reply to
Michael Schnell
Loading thread data ...

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

formatting link
and
formatting link
for a free download. Or even RTAI, which essentially the Free alternative to RTLinux.

Reply to
raseelbhagat

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.

Reply to
Geronimo W. Christ Esq

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

Reply to
Michael Schnell

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 ?

Reply to
Geronimo W. Christ Esq

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 ...

Reply to
Geronimo W. Christ Esq

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

Reply to
Michael Schnell

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

Reply to
Michael Schnell

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.

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.

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

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.

Reply to
Geronimo W. Christ Esq

Dont think 2.6 too seriously! you have to do much with it! new driver model,little improvements with complicated components

Reply to
风

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).

OK.

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

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

Reply to
Michael Schnell

"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

Reply to
Michael Schnell

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

formatting link

-Michael

Reply to
Michael Schnell

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

Reply to
Michael Schnell

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.