On 09/01/10 15:08, jan.gr...@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-unsubscr...@freebsd.org"
