I/O is the problem, not CPU

Posted Nov 19, 2010 10:13 UTC (Fri) by job (guest, #670)
Parent article: TTY-based group scheduling

When was the last time you actually pegged your CPU so the behaviour of the scheduler was important to you? Sure, some people who do render jobs or large compile jobs do this regularly, but I expect a growing amount of this to be done on dedicated hardware.

Personally I have a problem with disk I/O a lot more often. I suspect there is a significant amount of CPU work involved in SATA I/O and that this activity is not scheduled together with userspace, because when there is heavy disk usage interactivity in my terminals becomes very choppy.

This was actually better ten years ago, on yesterday's hardware, so something must have changed since then. If you want to help dekstop interactivity, test under disk activity first. Your users will thank you (at least I would).

to post comments

I/O is the problem, not CPU

Posted Nov 19, 2010 19:47 UTC (Fri) by Hypatia (guest, #57397) [Link]

I do peg my CPU with reasonable frequency, but You are right on with your point on I/O. Disk I/O is the bottleneck far more often than CPU is.

That said, I fear that with this scheduling scheme I will have to stop launching my headless VMs from the commandline, since they will be badly throttled while my wobbly windows wobble smoothly and my screen saver dazzles an empty room at high priority. I use the 'nice' command a lot , especially back in the days when I did a lot of kernel compiling. Nice has always worked pretty well for me. Is this patch different than auto-nicing your interactive bash shells?

I/O is the problem, not CPU

Posted Nov 20, 2010 18:16 UTC (Sat) by mfedyk (guest, #55303) [Link]

I peg my cpu with firefox all of the time, and I have a dual core 64 bit cpu. firefox also manages to use all 4 gb and full up swap until I get my tab count down to about 200 or so.

btw, chrome does the same with memory at about 50 tabs...