Bug 73245

Summary:	'swap-in' causes several second hesitation on mouse and keyboard input
Product:	Base System	Reporter:	Bob Frazier <bobf>
Component:	kern	Assignee:	Volker Werth <vwe>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	5.3-STABLE
Hardware:	Any
OS:	Any

Description Bob Frazier 2004-10-28 17:20:25 UTC

when an inactive process 'swaps out', several seconds can pass before the process will accept any input again if the process is re-activated.  This primarily takes place while xorg is running, though it is not restricted to xorg.  Even 'sysmouse' can stall if there is no mouse motion for an extended period of time, such that moving the mouse does not cause the mouse pointer to move at ALL for several seconds.  Typically it shows up in applications running in the background, such as 'xterm', where switching focus to them in 'X' via the mouse or ALT+TAB (or using ALT+Fx or CTRL+ALT+Fx to switch to another console, INCLUDING a logged out console) and then immediately typing does not echo the keys typed for several seconds.

Fix: 

If you periodically 'activate' an application, the delay doesn't happen.  It only seems to happen when an application (including a logged off console) is not activated for a significant period of time.
How-To-Repeat: a) run a gnome 2 session in xorg
b) open several applications (web browser, xterm sessions, e-mail, xchat, and so on).
c) use one of the applications for an extended period of time.  Leaving 'xchat' going in an active channel for 30 minutes should be sufficient.
d) use one of the normal methods (mouse motion, ALT+TAB, CTRL+ALT+Fx) to switch to a virtual console or a different application.  Type text in immediately.  Observe that in many cases, a delay occurs before the keys echo.

Comment 1 Giorgos Keramidas 2004-10-28 21:38:19 UTC

On 2004-10-28 16:20, bob frazier <bobf@mrp3.com> wrote:
> when an inactive process 'swaps out', several seconds can pass before
> the process will accept any input again if the process is
> re-activated.  This primarily takes place while xorg is running,
> though it is not restricted to xorg.

I've seen this happen on CURRENT too.  After a bit of testing I found out that
this does not happen if you set vm.swap_idle_enabled=0 in your `sysctl.conf'.

Can you try this and let me know if it works for you too?

Note though that this is a workaround, not a real fix of the real cause.

Comment 2 Robert Watson freebsd_committer

2008-03-08 20:01:43 UTC

State Changed
From-To: open->feedback

It's been a while since this report was made; are you able to reproduce the 
problem on a recent (FreeBSD 7.0) release?  Since the time of this report, 
a lot of work has been done on user interactivity, removing the Giant lock 
from storage drivers and file systems, etc, all of which may have helped 
with (or eliminated) this issue.  Thanks.

Comment 3 Volker Werth freebsd_committer

2008-05-10 18:07:26 UTC

State Changed
From-To: feedback->suspended


this problem is believed to have been fixed (needs testing) 
suspending this ticket due to no feedback 
it will be closed after 5.x EOL date (soon!)

Comment 4 Volker Werth freebsd_committer

2008-05-10 18:24:36 UTC

Responsible Changed
From-To: freebsd-bugs->vwe


track for EOL

Comment 5 Volker Werth freebsd_committer

2008-05-11 19:43:38 UTC

State Changed
From-To: suspended->closed


issue is reported as not occuring anymore. 
Quote from Bob by private mail: 
"this problem has not re-appeared for quite some time (I think it was specific to one particular version of 5.x)" 
Thanks Bob for reporting!