> there is a bug in this area though, we do not re-run the need_resched
> check _after_ running do_signal(). We always run the check even if
> user-space is interrupted, but the problem is that it has to be restarted
> after delivering a signal too. The preliminary fix for this against
> 2.3.34-pre1 is attached, does it solve your problems? [patch works here
> just fine]
>
OK, looks like the patch helps the case when a user process sends
a signal to another user process (do_signal), however, when a signal
is sent from a kernel event (rtc_interrupt or timer_bh) via the
send_sig & send_sig_info no resched check is done so a user process
may continue to run for a while.
223507.99 0.65 handle_IRQ_event pid(281)
223508.64 4.39 rtc_interrupt pid(281)
223513.03 0.86 __wake_up pid(281)
223513.90 0.71 kill_fasync pid(281)
223514.61 7.17 send_sigio pid(281)
^^^--- sends sigio to pid(156)
223521.78 0.37 send_sig pid(281)
223522.15 1.86 send_sig_info pid(281)
223524.00 1.33 ignored_signal pid(281)
223525.33 0.57 wake_up_process pid(281)
223525.90 6.65 reschedule_idle pid(281)
223532.56 0.85 mod_timer pid(281)
223533.41 0.84 enable_8259A_irq pid(281)
223534.25 0.15 do_IRQ pid(281)
223534.40 1216.48 do_IRQ pid(281)
^^^--- runs 1.2msec
224750.88 0.33 system_call pid(281)
224751.21 0.70 sys_write pid(281)
224751.91 0.36 sock_write pid(281)
224752.27 0.55 sock_sendmsg pid(281)
224752.82 0.63 inet_sendmsg pid(281)
224753.45 0.37 inet_autobind pid(281)
224753.82 0.28 tcp_v4_sendmsg pid(281)
224754.10 4.90 tcp_do_sendmsg pid(281)
224759.00 0.28 sock_wmalloc pid(281)
224759.28 0.43 alloc_skb pid(281)
224759.71 0.23 kmem_cache_alloc pid(281)
224759.94 1.95 schedule pid(281->156)
Only after pid(281) finally gets around to making a system
call does a resched occur. In some cases a user process
may be heavily compute bound and make very few system calls
which would probably increase latency even more.
I think the approach to check after a signal is sent is
a good one since a process waiting on a signal may one
that needs to run (higher priority). Is there a way to
do a resched after a kernel event sends a signal or is
that a bad thing?
Wm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/