Date: Wed, 23 Mar 2011 15:52:21 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: George Mitchell <george@m5p.com> Cc: freebsd-stable@freebsd.org Subject: Re: Firefox startup impacted by distributed.net client Message-ID: <20110323225221.GA91414@icarus.home.lan> In-Reply-To: <4D8A7305.5010805@m5p.com> References: <4D8A61FC.3050303@m5p.com> <AANLkTimeygQ%2BPb0UZjM2-6BpcDi2fDq8te7akY99FX4Y@mail.gmail.com> <4D8A7305.5010805@m5p.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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"<george+freebsd@m5p.com> 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 |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110323225221.GA91414>