freebsd stable - Sep 2010 - Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable.

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.

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.

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 
desktop has quite a lot of associated processes, and you can't keep them 
all sufficiently "interactive" in the eyes of sched_ule to ensure they
stay responsive.

Are there particular tunables associated with sched_ule (the manpage says 
not) that I might look at to try to address this? Or process flags I can 
set on my desktop tasks to keep them nearer the interactive end of the 
spectrum?

Claimed is:

           o   Interactivity heuristics that detect interactive applications
               and schedules them preferentially under high load.

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

At the moment I'm fiddling around with cpusets to try to pin my port 
builds to a subset of the available processors.

Suggestions are welcome!
Cheers,
jan

PS. I've stuck it out with sched_ule since it's been available, but I 
should point out this isn't a sudden change in its behaviour; it's done 
this for a while.

-- 
jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/
Tel +44 (0)117 3317661   http://ioctl.org/jan/
"No generalised law is without exception." A self-demonstrating axiom.

On 09/01/10 15:08, jan.grant@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.