Per CPU cpu-statistics under SMP

Marco van Tol marco at tols.org
Mon Apr 17 13:48:30 UTC 2006


On Mon, Apr 17, 2006 at 09:04:58AM -0400, John Baldwin wrote:
> 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:

[...]

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

Great thanks!

I will try to apply the patch, and try to modify gkrellm to support it.
I'll drop them (gkrellm developers) a note that I'm doing this, as it would
be a waist of effort if somebody else has been doing preliminary work that
I'd be doing again. :)

I'll keep you up-to-date.

Thanks.

Marco

-- 
Ik heb een hekel aan bumper-klevers, vanochtend zat er weer een voor me.


More information about the freebsd-hackers mailing list