From owner-freebsd-stable@FreeBSD.ORG Wed Mar 23 22:52:24 2011 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 21BAA106564A for ; Wed, 23 Mar 2011 22:52:24 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by mx1.freebsd.org (Postfix) with ESMTP id D56248FC19 for ; Wed, 23 Mar 2011 22:52:23 +0000 (UTC) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta14.westchester.pa.mail.comcast.net with comcast id NmsF1g0030xGWP85EmsQNj; Wed, 23 Mar 2011 22:52:24 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta12.westchester.pa.mail.comcast.net with comcast id NmsN1g02B1t3BNj3YmsPSG; Wed, 23 Mar 2011 22:52:24 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 6229B9B422; Wed, 23 Mar 2011 15:52:21 -0700 (PDT) Date: Wed, 23 Mar 2011 15:52:21 -0700 From: Jeremy Chadwick To: George Mitchell Message-ID: <20110323225221.GA91414@icarus.home.lan> References: <4D8A61FC.3050303@m5p.com> <4D8A7305.5010805@m5p.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D8A7305.5010805@m5p.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: Firefox startup impacted by distributed.net client 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, 23 Mar 2011 22:52:24 -0000 On Wed, Mar 23, 2011 at 06:24:05PM -0400, George Mitchell wrote: > On 03/23/11 17:57, Matthias Gamsjager wrote: > >Have you tried 8 stable? > > The box I tried SCHED_4BSD on was running 8.2_PRERELEASE, which still > had the problem described. Has the scheduler changed significantly > between 8.2_PRERELEASE and stable? -- George Mitchell > > >On 23 Mar 2011 22:12, "George Mitchell" wrote: > >>Original message, from ten months ago: > >> > >>http://lists.freebsd.org/pipermail/freebsd-hackers/2010-May/031915.html > >> > >>Briefly, running the distributed.net client on my FreeBSD 8.0 box > >>made Firefox take forever to start up (90 seconds vs. 2 seconds). > >>The distributed.net client is essentially 100% CPU bound, with > >>occasional file I/O and even more occasional socket I/O, running > >>at nice 20. The problem has persisted since then. > >> > >>So I finally compiled up a kernel using SCHED_4BSD instead of > >>SCHED_ULE. Problem fixed. > >> > >>It still doesn't give me a warm, fuzzy feeling about FreeBSD 8.0, > >>since I still have the awful NFS client performance problem (though > >>not as bad as before the Rick Macklem patch). -- George Mitchell No, it hasn't. You didn't provide any hardware details of your system in the link you referenced (post to -hackers). It matters. dmesg output (regardless of what scheduler you're using in the kernel) would be useful. Output from the command "sysctl kern.sched.topology_spec" might also help. So would your kernel configuration file. :-) Focusing solely on the first/main paragraph of your linked post (CPU usage and system responsiveness, not memory usage): There have been discussions in the past of SCHED_ULE not performing well on single-core systems, and lots of discussions of "unfriendly behaviour" caused on multi-core systems (where X is running and audio skips when doing things like moving a window, etc.). I believe one of the workarounds people recommended was to adjust the below sysctl, increasing it from 64 (default) to 224: kern.sched.preempt_thresh=224 I would recommend trying this if possible. It would at least rule out one thing for troubleshooting. The brief discussion (you might have to read/dig around the thread a bit) in question that I remember: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2010-09/msg00155.html http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2010-09/msg00157.html As for the next paragraph of your linked post (memory usage and firefox-bin): I can't explain what "ucond" represents in top. That is to say: I know what the STATE field is about, but I can't tell you code-wise what "ucond" represents functionally; my guess is some condition relating to a kernel mutex (thread lock). The relevant code bits in src/sys/kern/kern_umtx.c are over my head. I'm sure a kernel hacker can explain this, but it probably isn't relevant to your problem. -- | 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 |