Hello,
My machine has a similar behavior. For instance, during intensive
workload (portupgrade), everything is quite not-responsive.
I made an alias of portupgrade, nice -n 5 portupgrade, that solves the
problem just in that particular case.
My system is AMD Athlon(tm) 64 Processor 3000+ (1809.28-MHz 686-class
CPU) with openGL effects disabled, KDE as desktop environment.
There is an interesting mib kern.sched.interact. But I don't know the
meaning of it (my value is 30).
Cheers,
Luca
On 09/02/2010 12:46, jan.gr...@bristol.ac.uk wrote:
On Thu, 2 Sep 2010, Andriy Gapon wrote:
on 02/09/2010 12:08 jan.gr...@bristol.ac.uk said the following:
On Wed, 1 Sep 2010, Ivan Voras wrote:
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?
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.
From my experience:
1. system with Athlon II X2 250 CPU and onboard AMD graphics - no issues with
interaction between buildworld and GUI with all KDE4 effects enabled (OpenGL).
2. system with comparable Core2 Duo CPU and onboard Intel graphics (G33) -
enabling OpenGL desktop effects in KDE4 leads to the consequences like what you
describe. With all GUI bells and whistles disabled the system behaves quite
like the AMD system.
All desktop effects are disabled. The graphics are from an nVidia GeForce
8500 GT (G86) with the X.org driver. (It's not _just_ desktop behaviour
that's affected, though: the box runs a number of small headless
[interactive] server processes which also appear to get rapidly starved of
CPU time.)
The behaviour isn't visible with the 4bsd scheduler; "stuff" generally
remains snappy and responsive.
I'll keep poking around and see if I can get to the bottom of it.
--
Mit herzlichen Grüßen,
Luca Pizzamiglio
Systementwicklung
BALLY WULFF Entertainment GmbH
Maybachufer 48-51
12045 Berlin
Phone: +49(30)62002 149
_______________________________________________
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"
