> So there are at least a few device drivers which are apparently holding
> interrupts off long enough so that we lose a clock interrupt. Not good,
> and one of the reasons why any attempts to tweak the Linux scheduler to
> make it a "real-time system" simply elicits a smile from me..... oh, if
> only it were so easy! :-)
it's not that hard or hopeless as it seems. i wrote a tool for exactly
this reason, it measures driver delays pretty exactly by instrumenting
cli()/sti()/etc. It was used by people to 'finetune' particular RT
systems. (obviously you do not expect a typical PC to have all
well-behaving drivers, you pick a reasonable config and work out bugs)
Even on 'random' Linux systems there are not many uncontrollable delays
around, SCSI being the worst offender by far. Excluding SCSI, 99% of the
delays were well under 1 msec. (typically in the 'few usecs' range). Those
'scheduler tweaks' are pretty useful for soft-RT tasks, when buring CDs or
playing music.
there is another range of problems, schedule->schedule latencies (time
spent in a kernel 'atom'), i had a profiler for that one too, and around
2.0.30ish a few small patches went in to fix the worst offenders.
RTLinux is of course a far more superior solution if you need hard-RT.
-- mingo
-
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/