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. > > 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. _______________________________________________ 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"
