From owner-freebsd-stable@FreeBSD.ORG Wed Sep 1 13:26:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 548471065675 for ; Wed, 1 Sep 2010 13:26:24 +0000 (UTC) (envelope-from jan.grant@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id 17B8A8FC1C for ; Wed, 1 Sep 2010 13:26:23 +0000 (UTC) Received: from mail.ilrt.bris.ac.uk ([137.222.16.62]) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1Oqn3c-0002R3-Ca; Wed, 01 Sep 2010 14:08:55 +0100 Received: from cse-jg.cse.bris.ac.uk ([137.222.12.37]:61072) by mail.ilrt.bris.ac.uk with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Oqn3Y-0004tn-Hy; Wed, 01 Sep 2010 14:08:48 +0100 Date: Wed, 1 Sep 2010 14:08:48 +0100 (BST) From: jan.grant@bristol.ac.uk X-X-Sender: cmjg@tribble.ilrt.bris.ac.uk To: freebsd-stable@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ILRT-MailScanner: Found to be clean X-ILRT-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.41, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.99, BAYES_00 -2.60) X-ILRT-MailScanner-From: jan.grant@bristol.ac.uk X-Spam-Status: No X-Spam-Score: -1.1 X-Spam-Level: - Subject: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 13:26:24 -0000 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. 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. I don't think my desktop usage is particularly abnormal; I doubt my level of frustration is, either :-) I think the issue here is that a modern desktop has quite a lot of associated processes, and you can't keep them all sufficiently "interactive" in the eyes of sched_ule to ensure they stay responsive. Are there particular tunables associated with sched_ule (the manpage says not) that I might look at to try to address this? Or process flags I can set on my desktop tasks to keep them nearer the interactive end of the spectrum? Claimed is: o Interactivity heuristics that detect interactive applications and schedules them preferentially under high load. but compared to the performance under sched_4bsd, what I'm seeing is an atrocious user experience. At the moment I'm fiddling around with cpusets to try to pin my port builds to a subset of the available processors. Suggestions are welcome! Cheers, jan PS. I've stuck it out with sched_ule since it's been available, but I should point out this isn't a sudden change in its behaviour; it's done this for a while. -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ "No generalised law is without exception." A self-demonstrating axiom.