Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable.

[Ivan Voras]

On 09/01/10 15:08, jan.grant at bristol.ac.uk wrote:
> I'm running -STABLE with a kde-derived desktop. This setup (which is
> pretty standard) is providing abysmal interactive performance on an
> eight-core machine whenever I try to do anything CPU-intensive (such as
> building a port).
>
> Basically, trying to build anything from ports rapidly renders everything
> else so "non-interactive" in the eyes of the scheduler that, for instance,
> switching between virtual desktops (I have six of them in reasonably
> frequent use) takes about a minute of painful waiting on redraws to
> complete.

Are you sure this is about the scheduler or maybe bad X11 drivers?

> Once I pay attention to any particular window, the scheduler rapidly
> (like, in 15 agonising seconds or so) decides that the processes
> associated with that particular window are "interactive" and performance
> there picks up again. But it only takes 10 seconds (not timed; ballpark
> figures) or so of inattention for a window's processes to lapse back into
> a low-priority state, with the attendant performance problems.

"windows" in X11 have nothing to do with the scheduler (contrary to MS 
Windows where the OS actually "re-nices" processes whose windows have 
focus) - here you are just interacting with a process.

> I don't think my desktop usage is particularly abnormal; I doubt my level
> of frustration is, either :-) I think the issue here is that a modern

I'm writing this on a quad-core Core2 machine with 4 GB RAM, amd64 arch, 
Radeon 2500 HD, with KDE4 with most of the 3D visual effects turned on. 
I have not yet experienced problems like you describe.

On the other hand, I have noticed that a 2xQuad-core machine I have 
access too has more X11 interactivity problems than this single 
quad-core machine, though again not as serious as yours. I don't know 
why this is. From the hardware side it might be the shared FSB or from 
the software side it might be the scheduler. If you want to try 
something I think it's easier for you to disable one CPU in BIOS or pin 
X.org and its descendant processes to CPUs of a single socket than to 
diagnose scheduler problems.

> but compared to the performance under sched_4bsd, what I'm seeing is an
> atrocious user experience.

It would be best if you could quantify this in some way. I have no idea how.