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.
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"