> I've been reading POSIX 1003.13 RT standard and see that RTL could
> meet the "minimal real time system" spec without much pain. Does
> anyone out there care?
>
> The larger POSIX standard seems basically pointless for hard RT, although
> I'm looking for ideas on how to allow for "soft rt" linux processes.
> One idea would be to use the RTL tasks to control scheduling of Linux
> processes in response to queue lengths and other hints. Suggestions?
Yes this is a very good idea. The problem with things like "RTC interrupt"
waking up some linux process is that the wake up is often delayed until the
next or even second clock tick (up to 20 ms). Even if the process uses
something like:
shed_parm.sched_priority=10;
sched_setscheduler(0,SCHED_FIFO,&shed_parm);
it is still not woken up immediately after the interrupt. This has forced me
to use the kernel with HZ=1000 or more for my project.
I guess that RTC interrupt is a fast interrupt, which results in delay of
waking up the waiting process (no reshedule). There was once on linux-kernel
discussion about letting interrupt service routine return a value stating
whether rescheduling should be done, but I do not know whether it was
implemented.
Regards,
-- Tomasz Motylewski
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/