Firefox startup impacted by distributed.net client

[Jeremy Chadwick]

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:
> >>
> >>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 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 |