Date: Fri, 3 Sep 2010 13:50:10 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: Michal Varga <varga.michal@gmail.com> Cc: jan.grant@bristol.ac.uk, freebsd-stable@freebsd.org, Jim Bryant <kc5vdj.freebsd@gmail.com>, Luca Pizzamiglio <l.pizzamiglio@bally-wulff.de> Subject: Re: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable. Message-ID: <20100903205010.GA85105@icarus.home.lan> In-Reply-To: <1283544518.26203.33.camel@xenon> References: <alpine.BSF.2.00.1009011357050.5858@tribble.ilrt.bris.ac.uk> <i5lr29$9ei$1@dough.gmane.org> <alpine.BSF.2.00.1009021000110.50312@tribble.ilrt.bris.ac.uk> <4C7F7C0F.8080004@icyb.net.ua> <alpine.BSF.2.00.1009021133330.5858@tribble.ilrt.bris.ac.uk> <4C7F9ACE.80705@bally-wulff.de> <4C814665.3070306@gmail.com> <1283544518.26203.33.camel@xenon>
next in thread | previous in thread | raw e-mail | index | archive | help
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@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100903205010.GA85105>