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

.

Relevant Pages

  • Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5
    ... But anyway, based on the evidence, I think the problem is caused by the fact that the eatm tasks are running to completion in less than one time slice without sleeping and this means that they never have their priorities reassessed. ... The reason that it does this is that it gives newly forked processes a fairly high priority and if they're left to run for a full 120 msecs at that high priority they can hose the system. ... Having a shorter first time slice gives the scheduler a chance to reassess the task's priority before it does much damage. ...
    (Linux-Kernel)
  • Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5
    ... problem is that it uses a smaller time slice for the first time slice ... full 120 msecs at that high priority they can hose the system. ... shorter first time slice gives the scheduler a chance to reassess the ... This is supposed to represent the task with the highest CPU usage rate per share and is used to determine how fairly CPU is being distributed among the currently active tasks. ...
    (Linux-Kernel)
  • Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling
    ... system running your Realtime Preemption kernel. ... the nicescheduler provides no clear way to support ... the privilege issue using rlimits. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: Blocking read() policy?
    ... >> It doesn't require any particular advanced scheduler. ... Especially if pgms demanding short latency ... that a CPU intensive process would ... starts over with the shortest possible time slice. ...
    (comp.os.linux.development.system)
  • Re: [NT] Quantum of interrupted process
    ... operating systems. ... I believe a thread is not handed a time slice ... I believe any interruption time that a thread ... will the scheduler switch to P3 with Q3 ...
    (microsoft.public.development.device.drivers)