Date: Mon, 24 Apr 2006 08:23:48 -0400 From: John Baldwin <jhb@freebsd.org> To: Marco van Tol <marco@tols.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Per CPU cpu-statistics under SMP Message-ID: <200604240823.48948.jhb@freebsd.org> In-Reply-To: <20060423113335.GA27406@tols.org> References: <20060412215021.GB1146@tols.org> <20060420224049.GA99399@tols.org> <20060423113335.GA27406@tols.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 necessa= ry > 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 yo= ur > email adres, or make it available on my website. :) > > Marco Well, the goal of the patch was to provide a small performance optimization= by=20 holding sched_lock for a shorter period of time. Curiously, it actually=20 resulted in a performance decrease on i386 and amd64 in benchmarks. On a 1= 0=20 cpu sparc64 machine it did result in an improvement. I need to do more=20 research to determine why it would hurt performance for the x86 case (even = on=20 4 cpu boxes) as I don't want to go committing things that hurt performance.= =20 If I can address the performance problems though this is the interface that= =20 would be presented to userland. =2D-=20 John Baldwin <jhb@FreeBSD.org> =A0<>< =A0http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =A0=3D =A0http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200604240823.48948.jhb>