Date: Thu, 2 Sep 2010 10:08:21 +0100 (BST) From: jan.grant@bristol.ac.uk To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-stable@freebsd.org Subject: Re: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable. Message-ID: <alpine.BSF.2.00.1009021000110.50312@tribble.ilrt.bris.ac.uk> In-Reply-To: <i5lr29$9ei$1@dough.gmane.org> References: <alpine.BSF.2.00.1009011357050.5858@tribble.ilrt.bris.ac.uk> <i5lr29$9ei$1@dough.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 1 Sep 2010, Ivan Voras wrote: > 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? 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. > > 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. Yup, and it does seem that by interacting with the process, things'll start to pick up again - for the processes associated with that window. > 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. Yeah, I realised that my report was "this doesn't work [very well]!" which is fairly terrible when it comes to tracking things down; mostly, I was hoping to prompt none, some or lots of "same here"s to see if the problem was commonly seen. Also (as you're aware) a desktop environment is a complex beast, and putting numbers against "look and feel" is tricky - however in this situation, I can get numbers from a wall-clock, the behaviour is that pronounced. I'll certainly try getting the whole X tree onto a single socket, to see if that makes any difference. I'll certainly have a stab with your suggestion - thanks Ivan. -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ Q: What's yellow and equivalent to the axiom of choice? A: Zorn's lemon.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1009021000110.50312>