Come on, we've all seen the code. Scanning the longer run
queue is the _only_ thing that's done when you have a
long run queue. If you've read the code, you'll reach
the same conclusion I reached...
> > > I'm very skeptical of loose use of the term RT. Are these tasks of yours
> > > really RT? Hard? Soft? Statistical?
> >
> > They are fairly hard and are triggered from an interrupt. After
>
> "Fairly hard" means absolutely nothing at all.
Yes it does. It means that the maximum latency is short.
Hard means nil latency and soft means we don't care that
much. The app in question is somewhere in between, but
closest to real hard RT.
> > > How? It's quite simple as it is.
> >
> > Reducing overall simplicity is not the goal. The main goal
>
> Coulda fooled me.
OK, you tell me what's better:
1) a simple system with a fair worst-case latency for RT tasks
2) a slightly more complex system with excellent worst-case
latency for RT tasks and a slightly worst latency for non-RT
tasks
3) a horribly complex and slow system, which nobody is proposing
since we can buy NT if we want one of these :)
Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
-
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/