On Friday 08 October 2004 10:56 pm, Sam Lawrance wrote: > I think I've found the cause of the delays. > > The problem was consistently reproducible with getty processes which are > swapped out (ie 'ps' shows RSS=0 and state=IWs+). > > Since the problem was identifiable when starting to type at a vty, I > traced the problem back through: > > ttyinput() : tty.c > ttwakeup() : tty.c > wakeup() : kern_synch.c > sleepq_broadcast() : subr_sleepq.c > sleepq_resume_thread() : subr_sleepq.c > setrunnable() : kern_synch.c > > Notice in setrunnable() how wakeup(&proc0) is wrapped by #ifndef SMP? > This means that scheduler() : vm/vm_glue.c, which tsleeps on proc0, is > not awoken to traverse the process list and swap the process in. > > scheduler() tsleeps for a maximum of maxslp * hz / 2. maxslp on all > archs appears to be 20, so the actual wakeup intended by ttwakeup() may > not occur for up to 10 seconds. I think I agree, FWIW. Marc. -- Marc Ramirez Blue Circle Software Corporation 513-688-1070 (main) 513-382-1270 (direct) http://www.bluecirclesoft.com http://www.mrami.com (personal)
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:16 UTC