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

[Jeremy Chadwick]

On Fri, Sep 03, 2010 at 10:08:38PM +0200, Michal Varga wrote:
> On Fri, 2010-09-03 at 14:03 -0500, Jim Bryant wrote:
> > i just noticed this too...  had a build going of qt-creator, and then 
> > started a /usr/src make clean, and had to abort the qt-creator build to 
> > get the make clean to finish.  it was taking forever to even paint the 
> > xterm in the make clean window.
>
> ... 
> 
> On the other hand, at least from some of my observations, the terrible
> desktop performance isn't strictly CPU-bound, I/O definitely has some
> say in this. You can (you should, mileage may vary) see this by trying
> to extract a few-GB archive in the background. While clearly no more
> than a single CPU is ever occupied by that process (and there's few
> other happily idling), you can spend waiting up to a few minutes just to
> get a new application launched (or even just a running one getting
> redrawn, in case part of it was swapped out at the moment).

Could this be caused by lack of disk I/O scheduler on FreeBSD, at least
with regards to launching a new application?  Can you try making use of
gsched(8) and see if things improve in this regard?

Just be aware of this problem[1] when using it.  (I've been working on a
proper fix -- not a hack -- for the problem for about a week now.
Stress level is very high given the ambiguous nature of many aspects of
GEOM and libgeom lacking in numerous areas.  So far I've managed to
figure out how to parse the results from geom_gettree() in attempt to
replace kern.geom.conftxt...)

[1]: http://lists.freebsd.org/pipermail/freebsd-current/2010-April/016883.html

-- 
| Jeremy Chadwick                                   jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |