On Tue, Mar 21, 2000 at 10:45:25AM -0800, Jun Sun wrote:
> Jamie Lokier wrote:
> >
> > yodaiken@fsmlabs.com wrote:
> > > As far as I can tell,
> > > only place need_resched is set is in the scheduler and the sched idle loop.
> > > This is what makes Ingo's latency patch less dangerous: need_resched is hard
> > > to set. Your scenario requires that an interrupt routine, interrupting
> > > kernel mode, set needs_resched. Where does this happen?
> >
> > Whenever an interrupt wakes up a process. Alan says it's uncommon, but
> > it depends what devices you're using. Some device drivers do it for all
> > interrupts, if a process is waiting for some information from the device.
> >
> > -- Jamie
>
> I don't know much about existing drivers. I know for embedded systems,
> processes reading files and getting blocked, interrupt handlers (or its
> bottom-half handler) waking them up is *VERY COMMON*.
>
> I do agree that the window is small. (That is the reason I have to
> patch kernel in order to deterministically create the scenario in my
> test)
> Unfortunately, for most embedded systems, 99.99% of times being correct
> is not good enough.
I agree that you found a bug, I disagree that you will ever get 100% timing
correctness from Linux except at the cost of making the kernel unmaintainable.
Furthermore, if you do similar timing tests on VxWorks, Win-CE, and etc, I bet
you will find that 100 milliseconds is not impossible.
Note that even QNX quotes "typical" interrupt latency times.
-- --------------------------------------------------------- Victor Yodaiken FSMLabs: www.fsmlabs.com www.rtlinux.com FSMLabs is a servicemark and a service of VJY Associates L.L.C, New Mexico.- 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/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:34 EST