Per CPU cpu-statistics under SMP

[John Baldwin]

On Saturday 15 April 2006 06:40 am, Marco van Tol wrote:
> On Fri, Apr 14, 2006 at 10:17:29AM -0400, John Baldwin wrote:
> > On Friday 14 April 2006 06:38, Marco van Tol wrote:
> > > On Thu, Apr 13, 2006 at 10:20:40AM -0400, John Baldwin wrote:
> > > > On Wednesday 12 April 2006 17:50, Marco van Tol wrote:
> > > > > Hi there,
> > > > >
> > > > > My apologies if this is the wrong list to ask this kind of
> > > > > question. I would appreciate a pointer to the correct list if it is
> > > > > please. :)
> > > > >
> > > > > I noticed in the code for gkrellm /usr/ports/sysutils/gkrellm2 that
> > > > > SMP per-cpu statistics were not yet supported under FreeBSD, and
> > > > > decided to check whether I could add that.  (I'm running a
> > > > > (dual-core) Athlon64 X2 with FreeBSD 6.1-PRERELEASE)
> > > > > I can't find sample code and/or documentation on how to acquire
> > > > > that information from the kernel.
> > >
> > > [...]
> > >
> > > > > Is there an interface under FreeBSD to acquire the necessary
> > > > > per-cpu statistics?
> > > >
> > > > They don't exist currently.  I have a patch to make the stats per-CPU
> > > > for performance reasons (though it only helps out on systems with
> > > > lots of CPUs (like 10) and hurts on systems with fewer CPUs (like
> > > > 4)).  It doesn't include a sysctl to get the per-CPU stats, but I
> > > > could add one.
> > >
> > > OK, that I could use to get started on the code for adding per-CPU
> > > stats to gkrellm under FreeBSD.  Is the patch against FreeBSD CURRENT?
> > >
> > > Then if the per-CPU stats code hits the STABLE trunk, it's likely to be
> > > only a few changes to what I did perhaps. Or am I running a bit to far
> > > ahead here? :)
> > >
> > > Is the patch in available your home area on www.freebsd.org?
> >
> > An early one but it doesn't export the data to userland yet.  I need to
> > figure out what interface to use for that.  I could have the cp_time
> > sysctl just include the CPU arrays after the global array and key
> > off the passed in length to determine if they should be included or not.
>
> I must admit that I had to read up a bit to understand what you meant here,
> but I think I do now.  I think it should work.
> If I understand correctly, the first array would have the composite CPU
> stats, and following arrays would be the CPU specific stats. Right?
> That'd be just like the linux /proc/stat.
>
> In case it's going to be done like this, will the sum of the CPU specific
> stats be the composite stats?

Yes.

> I'm not familiar with the formal process of adding/changing sysctl's for
> the kernel, so can't give much more comment. :)
> I'm assuming there are formal guidelines to do things like that.

I actually did it differently though to try and make it less confusing.
I've added a kern.pcpu_time sysctl which is an array of 0..mp_maxid
cp_time[] arrays (so (mp_maxid + 1) * CPUSTATES longs) which is just the
per-CPU data.  Userland can sum them up if it wants a composite total.
Userland would first do a sysctl with a NULL buffer to get the required
size (since it can vary with the number of CPUs in the system), malloc()
a buffer, and then use the malloc'd buffer to make the requests.  You
should only have to do the malloc() at process start since FreeBSD doesn't
currently allow for more CPUs to be added at runtime.  You can try out
the patch at http://www.FreeBSD.org/~jhb/patches/cp_time.patch

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