Messages in this thread | | | Date | Fri, 17 Dec 1999 17:21:05 -0500 (EST) | From | William Montgomery <> | Subject | Re: [patch] entry.S fix. [was: Re: scheduling problem?] |
| |
On Fri, 17 Dec 1999, Ingo Molnar wrote:
> 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/
| |