Re: [PATCH] [IMPORTANT] Re: 2.4.7 softirq incorrectness.

From: Nigel Gamble (
Date: Mon Jul 30 2001 - 17:47:51 EST

On Mon, 30 Jul 2001, Ingo Molnar wrote:
> > > I think the latency issue was really the fact that we weren't always
> > > running softirqs in a timely fashion after they had been disabled by a
> > > "disable_bh()". That is fixed with the new softirq stuff, regardless of
> > > the other issues.
> nope. i observed latency issues with restart + ksoftirqd as well. [when i
> first saw these latency problems i basically had ksoftirqd implemented
> independently from your patch, and threw the idea away because it was
> insufficient from the latency point of view.] Those latencies are harder
> to observe because they are not 1/HZ anymore but several hundred millisecs
> at most. Plus, like i said previously, pushing IRQ context work into a
> scheduler-level context 'feels' incorrect to me - it only makes the
> latencies less visible. I'll do some measurements.

If you schedule ksoftirqd as SCHED_FIFO or SCHED_RR, and run with the
preemptible kernel patch, you can get maximum latencies down to a few
hundred microseconds most of the time, with typical latencies of a few
tens of microseconds. Perhaps you could also measure that
configuration? (Latest preemptible kernel patch is available at

I'd like to see all the various execution contexts of Linux (irqs,
softirqs, tasklets, kernel daemons) all become (real-time where
necessary) kernel threads like ksoftirqd, scheduled with the appropriate
scheduling class and priority. The resulting kernel code would be much
simpler and more maintainable; and it would make it possible to change
the scheduling priority of the threads to optimize for different
application loads.

Nigel Gamble
Mountain View, CA, USA.

MontaVista Software

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 21:00:47 EST