Re: Noticable Delays Since Beta 3 (possible cause)

Sam Lawrance wrote:
> On Thu, 2004-10-07 at 11:31 -0600, Scott Long wrote:
> 
>>Doug White wrote:
>>
>>>On Thu, 7 Oct 2004, Benjamin Close wrote:
>>>
>>>
>>>
>>>>   I've been using each Beta Release as they come out and ever since
>>>>Beta 3 I've noticed delays where there never used to be any.
>>>>I believe this may be somehow related to ULE->BSD scheduler change. A
>>>>classic situation of where they now exist is when I switch virtual
>>>>desktops back to another xterm. It takes 4-5 seconds before I can type.
>>>>The machine is virtually 100% idle. Before beta3 this was not a problem
>>>>with almost an instant response.
>>>
>>>
>>>Can you provide a reproduction case? I don't notice any sort of delay when
>>>switching between text vtys, or changing keyboard focus in X. I've been
>>>using 4BSD the entire time.
>>>
>>>Are you switching between X and text vty's? There's always been a delay
>>>there, worse on my amd64 box than i386, but I don't do that regularly;
>>>much easier to just pop another xterm :)
>>>
> 
> 
> 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.

there used to be another place that started bringing in the pages..
I think someone removed it..
(I'm just going on memories..)

> 
> 
> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"