Re: MAXCPU preparations

From: Sean Bruno <seanbru_at_yahoo-inc.com>
Date: Mon, 27 Sep 2010 14:08:51 -0700
On Mon, 2010-09-27 at 12:41 -0500, Attilio Rao wrote:
> 2010/9/27 Sean Bruno <seanbru_at_yahoo-inc.com>:
> > On Mon, 2010-09-27 at 08:53 -0700, Julian Elischer wrote:
> >> On 9/27/10 8:26 AM, Sean Bruno wrote:
> >> > Does this look like an appropriate modification to libmemstat?
> >> >
> >> > Sean
> >> >
> >> >
> >> > ==== //depot/yahoo/ybsd_7/src/lib/libmemstat/memstat.h#4
> >> > - /home/seanbru/ybsd_7/src/lib/libmemstat/memstat.h ====
> >> > _at__at_ -28,12 +28,13 _at__at_
> >> >
> >> >   #ifndef _MEMSTAT_H_
> >> >   #define        _MEMSTAT_H_
> >> > +#include<sys/param.h>
> >> >
> >> >   /*
> >> >    * Number of CPU slots in library-internal data structures.  This
> >> > should be
> >> >    * at least the value of MAXCPU from param.h.
> >> >    */
> >> > -#define        MEMSTAT_MAXCPU  64
> >> > +#define        MEMSTAT_MAXCPU  MAXCPU /* defined in
> >> > sys/${ARCH}/include/param.h */
> >> >
> >>
> >>
> >> wouldn't it be better to do a sysctlbyname() and use the real value
> >> for the system?
> >>
> >
> > That was my initial thought (as prodded by scottl and peter).
> >
> > If it is made dynamic, could this be opening a race condition where the
> > call to sysctlbyname() returns a count of CPUS that is in turn changed
> > by the offlining of a CPU?  Or am I thinking to much about this?
> 
> We still can't support CPU hotplugging so the easy answer is 'don't
> bother about variadic CPUs number'.
> I don't really know what libmemstat is willing to do with that macro
> (and I don't have time to look at it now) maybe you could shade a
> light about what's its usage? Does it really needs to know MAXCPUS or
> just wants a large enough value to fill anything?
> 
> Thanks,
> Attilio
> 
> 

Give or take, MEMSTAT_MAXCPU is used to allocate an array of per cpu
stats (see lib/libmemstat/memstat_internal.h::struct memory_type).

If the number of probed CPUs is more that this value, the library
returns an error.



Sean
Received on Mon Sep 27 2010 - 19:09:22 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:07 UTC