Firefox startup impacted by distributed.net client
freebsd at jdc.parodius.com
Wed Mar 23 22:52:24 UTC 2011
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 at m5p.com> wrote:
> >>Original message, from ten months ago:
> >>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:
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:
As for the next paragraph of your linked post (memory usage and
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 at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP 4BD6C0CB |
More information about the freebsd-stable