Messages in this thread | | | Date | Tue, 22 Jan 2002 11:57:00 +0100 | From | Peter Wächtler <> | Subject | Re: [2.4.17/18pre] VM and swap - it's really unusable |
| |
Mark Hahn schrieb: > > > > > To me the benefit is clear enough: ASAP scheduling of IO threads, a > > > > simple heuristic that improves both throughput and latency. > > > > > > I think of "benefit", perhaps naiively, in terms of something that can > > > be measured or demonstrated rather than just announced. > > > > But you see why asap scheduling improves latency/throughput *in theory*, > > don't you? > > NO, IT DOES NOT. why can't you preempt-ophiles get that through your heads? > > eager scheduling is NOT optimal in general. > > for instance, suppose my disk can only read a sector at a time. > scheduling my sequentially-reading process to wake eagerly > is most definitly PESSIMAL. laziness is a cardinal virtue! > this doesn't preclude heuristics to sometimes short-cut the laziness. >
Do you think there are no other benefits besides the scheduling latency in a realtime system?
In a realtime system you want your event handling code (outside of the interrupt handler [on Linux: bottom halves/tasklets/sorftirq?) get running on the CPU as fast as possible. Therefore a realtime kernel is often fully preemptible (well, there are always critical sections that has to disable interrupts).
So the time between the interrupt handler wanting to schedule a specific task/thread and the next scheduling decision is crucial, right?
I have no hard numbers, but I can imagine that this can also lead to better IO (in terms of latency AND IO throughput but with the cost of cpu cycles [user space CPU throughput]).
I don't know the Linux kernel good enough right now, but if you shorten the scheduling latency: that could be a win for faster IO. But there's always a tradeoff: if you spent too much time in scheduling decisions/preparations the overhead eats the lower latency (especially if your mutexes have to deal with priority inversion, giving a lock holder at least the same priority as the lock contender for the period it holds the lock). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |