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

[jan.grant at bristol.ac.uk]

On Wed, 1 Sep 2010, Ivan Voras wrote:

> 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?

Not 100%, but mostly convinced; I've just started looking at this. It's my 
first stab at what might be going on. X11 performance is usually pretty 
snappy. There's no paging pressure at all.

> > 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.

Yup, and it does seem that by interacting with the process, things'll 
start to pick up again - for the processes associated with that window.


> 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.

Yeah, I realised that my report was "this doesn't work [very well]!" which 
is fairly terrible when it comes to tracking things down; mostly, I was 
hoping to prompt none, some or lots of "same here"s to see if the problem 
was commonly seen. Also (as you're aware) a desktop environment is a 
complex beast, and putting numbers against "look and feel" is tricky - 
however in this situation, I can get numbers from a wall-clock, the 
behaviour is that pronounced. I'll certainly try getting the whole X tree 
onto a single socket, to see if that makes any difference.

I'll certainly have a stab with your suggestion - thanks Ivan.

-- 
jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/
Tel +44 (0)117 3317661   http://ioctl.org/jan/
Q: What's yellow and equivalent to the axiom of choice? A: Zorn's lemon.