lkml.org 
[lkml]   [1997]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Patches to speed up SLIP and PPP

On Sat, 26 Apr 1997, Linus Torvalds wrote:

> (a) gets rid of the "fast" vs "slow" interrupts. They used to make sense,
> but they don't much do that any more. They only result in problems.

just to back up this with some hard numbers, here is a trace that shows a
full timer interrupt return path. Everything is done here, bottom half
handling, rescheduling to another process and signal handling:

[ trace was done on a 100 MHz Pentium, the interrupt happened in a quite
cache-cold situation, thats why numbers are 50% higher than one would
expect ]

---------------------------------------------------->
Trace: c010c8f8 <*IRQ_ENTRY*+10/64> (0.37)
Trace: c011089e <pentium_timer_interrupt+e/94> (0.12)
Trace: c0113035 <do_timer+d/8c> (1.91)
Trace: c011bb48 <*IRQ_EXIT*+8/10> (0.76)
Trace: c011a06b <do_bottom_half+f/74> (0.03)
Trace: c011bb58 <*BH_ENTRY*+8/10> (0.27)
Trace: c0112ce3 <timer_bh+13/358> (0.84)
Trace: c0112b62 <update_wall_time+e/58> (0.03)
Trace: c0112a87 <update_wall_time_one_tick+f/dc> (0.39)
Trace: c0112bbf <update_process_times+13/124> (2.06)
Trace: c0123539 <swap_tick+d/c0> (3.81)
Trace: c011971e <it_real_fn+e/54> (0.93)
Trace: c0118233 <send_sig+13/174> (3.16)
Trace: c0111e3a <wake_up_process+e/70> (3.02)
Trace: c011bb68 <*BH_EXIT*+8/10> (0.41)
Trace: c0111f27 <schedule+13/258> (9.73)
Trace: c010a38f <do_signal+13/294> (2.21)
Trace: c010a2ef <handle_signal+f/9c> (1.76)
Trace: c010a13c <setup_frame+10/1b4> (6.05)
Trace: c010a0a0 <save_i387+10/9c> (10.79)
Trace: c011bb08 <*SYS_EXIT*+8/10> (3.85)
Trace: c011baf7 <*SYS_ENTRY*+17/20> (1.05)
Trace: c0109eff <sys_sigreturn+f/1a0> (4.92)
Trace: c0109e84 <restore_i387+10/7c> (3.62)
Trace: c011bb08 <*SYS_EXIT*+8/10> (4.04)
<-------------------------------------------------

Summary of latencies:

"slow" irq entry part ------------- 0.37 usecs
irq handler ----------------------- 2.03 usecs
"slow" irq exit part -------------- 0.76 usecs
timer bottom half handler --------- 16.30 usecs
"slow" irq resched decision part -- 0.41 usecs
rescheduling to another process --- 10.14 usecs
setting up the signal ------------- 20.81 usecs
user-space handling the signal ---- 9.82 usecs
restoring pre-signal context ------ 3.62 usecs

The summary latency of all the "slow" part is 1.54 usecs. Total summary of
the interrupt-generated latencies: 59.10 usecs. The "slow" part isnt slow
at all.

I would suggest we make _every_ current 'fast' interrupt handler a 'slow'
interrupt handler that defaults to 'no extra processing to be done' [the
migration phase could be done by simply detecing the SA_INTERRUPT flag in
do_IRQ], and get rid of do_fast_IRQ()? Later then all interrupt handlers
make up their mind, and do_IRQ() does no decision and sa_flag detection.

or alternatively we could simply branch off in request_irq(), and give
every 'fast' interrupt a special small wrapper function that returns 'no
extra processing to be done'. This way no special casing is done in
do_IRQ() itself.

later then request_irq() could print a warning about the obsolete
SA_INTERRUPT flag?

and we can only win: one robust interrupt concept, smaller code, irq.h
assembly code _halved_ ;), plus the extra feature: "smart interrupts".

-- mingo


\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.789 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site