Re: [PATCH] Replace timer_bh with tasklet

[george anzinger <george@mvista.com>]

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