Per CPU cpu-statistics under SMP

John Baldwin jhb at freebsd.org
Mon Apr 24 12:41:13 UTC 2006


On Sunday 23 April 2006 07:33 am, Marco van Tol wrote:
> On Fri, Apr 21, 2006 at 12:40:49AM +0200, Marco van Tol wrote:
> > On Wed, Apr 19, 2006 at 07:26:27AM +0000, Marco van Tol wrote:
> > > On Tue, Apr 18, 2006 at 06:38:26PM -0400, John Baldwin wrote:
> >
> > [...]
> >
> > > > Ah, hmm.  On 6.x we don't have per-thread stat ticks yet, which is
> > > > probably why it is failing.  It also isn't safe to move sched_lock
> > > > down either on 6.x.  You can still apply the rest of the patch by
> > > > hand, just leave the 'mtx_lock_spin(&sched_lock)' where it is and
> > > > change all the 'cp_time[FOO]++' to 'PCPU_LAZY_INC(cp_time[FOO])'.
> > >
> > > OK, thanks.
> > >
> > > What I will do is replace my gentoo partition with a BSD current
> > > partition so I don't loose my workstation as it were, and use that to
> > > work on this.
> > >
> > > Will let you know how that goes.  Thanks.
> >
> > Ha! It succeeded. :)
>
> [...]
>
> I got it to work in non-client/server mode, and am working on making it
> also work in client/server mode. (gkrellmd as opposed to gkrellm)
>
> Is there anything you can say regarding an estimate on when per-cpu
> specific stats will hit the official CURRENT and STABLE branches?
>
> Are you interested in what I did to gkrellm so far?  All that was necessary
> was a small patch to src/sysdeps/freebsd.c in the gkrellm tree as far as
> making it work with your patch was concerned.  I can send the patch to your
> email adres, or make it available on my website. :)
>
> Marco

Well, the goal of the patch was to provide a small performance optimization by 
holding sched_lock for a shorter period of time.  Curiously, it actually 
resulted in a performance decrease on i386 and amd64 in benchmarks.  On a 10 
cpu sparc64 machine it did result in an improvement.  I need to do more 
research to determine why it would hurt performance for the x86 case (even on 
4 cpu boxes) as I don't want to go committing things that hurt performance.  
If I can address the performance problems though this is the interface that 
would be presented to userland.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org


More information about the freebsd-hackers mailing list