Re: [PATCH] Replace timer_bh with tasklet

george anzinger
2002-06-18T18:08:00Z

Linus Torvalds wrote:
>
> On Mon, 17 Jun 2002, george anzinger wrote:
> >
> > This patch replaces the timer_bh with a tasklet. It also introduces a
> > way to flag a tasklet as a must run (i.e. do NOT kick up to ksoftirqd).
> >
> > It make NO sense to pass timer work to a task.
>
> I hate adding infrastructure that isn't needed.
>
> Is there any reason why it would be _wrong_ to pass the timer work to a
> task? In particular, is it really any more wrong than anything else?
>
> I don't see that there is any difference between a timer bh and any other
> BH.

I reasoned that the timers, unlike most other I/O, directly drive the system.
For example, the time slice is counted down by the timer BH. By pushing the
timer out to ksoftirqd, running at nice 19, you open the door to a compute
bound task running over its time slice (admittedly this should be caught on
the next interrupt). Also, a great deal of the system depends on timers to
expire reasonably close to the correct time and not to be delayed by
scheduling decisions (oops, recursion).

As to infrastructure, why is ksoftirqd needed at all? IMNSHO it introduces
system overhead just when the system is most loaded. The work must be done
sometime soon in any case. Interrupts are on so all we are gaining is a bit
of responsiveness in the current task. But who is to say that the more
important task isn't being held off by the delay introduced by the
ksoftirqd "feature".

I do think that it would be a good thing to move some BH processing to the
task level, but I think it must be done selectively AND that there should
be a task per BH. That task should also be adjusted in priority, to the
users requirements. This would allow, for example, the network BH code
to run at a mid level priority such that some real time tasks could
preempt it, while others could be preempted by it.

But today we are just trying to say that of all the BH handlers, the
timer BH, since it drives the scheduler, is more important than other BHs.
>
> Linus
>
> PS. Your email is also seriously whitespace-damaged, so the patch
> wouldn't have worked anyway.

Sigh, I know.... Lets agree on what is to be done and I will cut a new patch...
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Real time sched: http://sourceforge.net/projects/rtsched/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml