Con Kolivas returns with a new scheduler [LWN.net]

Con Kolivas returns with a new scheduler

Posted Sep 3, 2009 2:37 UTC (Thu) by charris (subscriber, #13263)
In reply to: Con Kolivas returns with a new scheduler by jzbiciak
Parent article: Con Kolivas returns with a new scheduler

I find that gnome terminals will ignore my bluetooth keyboard for up to several seconds. I don't know if this is because of the bluetooth driver, X, or the scheduler, but it sure is annoying. And this on a 3GHz quad core system.

(Log in to post comments)

Con Kolivas returns with a new scheduler

Posted Sep 3, 2009 13:15 UTC (Thu) by nix (subscriber, #2304) [Link]

It's certainly not the bluetooth driver or X, because I see this on the console of a one-die four-core Nehalem (Core i7) with no X running at all and a PS/2 keyboard. It's lightly loaded by these standards (load average 8.1, which as it's hyperthreaded is pretty much equivalent to 'everything loaded but not much'), and surely isn't swapping (12Gb RAM, 6Gb *free*, not even used for cache). Yet I see three-second pauses in keyboard activity.

I'll turn on latencytop and see what it says, but the pauses are fairly rare so it might be interesting to interpret.

Con Kolivas returns with a new scheduler

Posted Sep 3, 2009 13:39 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]

I've only gotten multi-second pauses like that when I had a hard drive going bad, or I was swapping rather furiously.

With that much RAM, I wonder if VM housekeeping itself could cause such lags. 12Gb would have 3 million 4K pages. If you are running at 3GHz and did something that averaged 3000 cycles/page across all 3 million pages, that's 3 seconds.

Con Kolivas returns with a new scheduler

Posted Sep 3, 2009 17:31 UTC (Thu) by charris (subscriber, #13263) [Link]

I also see "stuck" keys where a letter will repeat until the buffer is full. I see this on various hardware with various keyboards, so it isn't an actual stuck key. Do you see that also?

Con Kolivas returns with a new scheduler

Posted Sep 3, 2009 18:14 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]

That sounds more like a dropped event somewhere such as dropped interrupt or the like. I haven't experienced that on any Linux box so far.

Stuck keys.

Posted Sep 4, 2009 2:47 UTC (Fri) by ncm (subscriber, #165) [Link]

I've seen on 2.6.29. Unplugging and re-plugging the (USB) keyboard didn't fix it. Only switching to console and back did it. I was inclined to blame the new X input system. It hasn't happened since I upgraded X and also went to 2.6.30, so who knows?

Input pauses

Posted Sep 4, 2009 4:09 UTC (Fri) by ncm (subscriber, #165) [Link]

I see input-event stalls for up to six seconds in Firefox (Debian Iceweasel, actually), routinely. To get it I just have to leave it running for a week or so, with a few dozen pages, some of which self-update.

I doubt the scheduler would help; during those six seconds, one CPU is pegged at 100%. This is with nothing swapped. I suspect it's doing a garbage collection scan during each pause. I'd welcome suggestions for how to discover what's going on.

Google Chrome is coming along too slowly.

Input pauses

Posted Sep 4, 2009 4:32 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link]

I know Firefox's stalls are Firefox's fault, not the Linux scheduler's. I was begging Con to do interactivity work on Firefox. ;-)

(As in, contribute to the Mozilla team.)

Input pauses

Posted Sep 4, 2009 8:17 UTC (Fri) by Cato (subscriber, #7643) [Link]

I've had these pauses for several seconds sometimes in Firefox 3.5.2, but they seem to be associated with large writes e.g. un-tarring a huge file at the same time - so I suspect it's the well known "Firefox 3.0 + ext3 + fsync" issue, reported in http://lwn.net/Articles/284126/ and elsewhere.