Date: Mon, 27 Sep 2010 17:38:19 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: "sbruno@freebsd.org" <sbruno@freebsd.org>, Robert Watson <rwatson@freebsd.org>, Sean Bruno <seanbru@yahoo-inc.com>, "current@freebsd.org" <current@freebsd.org> Subject: Re: MAXCPU preparations Message-ID: <201009271738.19497.jhb@freebsd.org> In-Reply-To: <alpine.BSF.2.00.1009272210040.69239@fledge.watson.org> References: <1285601161.7245.7.camel@home-yahoo> <1285604516.7245.16.camel@home-yahoo> <alpine.BSF.2.00.1009272210040.69239@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, September 27, 2010 5:21:31 pm Robert Watson wrote: > > On Mon, 27 Sep 2010, Sean Bruno wrote: > > >> wouldn't it be better to do a sysctlbyname() and use the real value for the > >> system? > > libmemstat contains some useful sample code showing how this might be done. > > > 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? > > Yes, you are. MAXCPU is a compile-time constant for kernel builds, so (at > least a the world is today), that can't happen. > > I think there's a reasonable argument that MEMSTAT_MAXCPU should be phased out > and all internal structures in libmemstat should be dynamically sized. > However, core counts aren't growing that fast, and it's quite a bit of work, > and probably not worth it just yet. > > I'm somewhat averse to using MAXCPU in libmemstat, however, because MAXCPU is > actually not a constant in the general case: FreeBSD/i386, for example, > regularly uses two different values: 1 for !SMP kernels, and 32 for SMP > kernels. That's why libmemstat encodes its own value, for better or worse. > > A reasonable alternative would be to replace 32 with MAXCPU * 2, or if we're > feeling particularly optimistic, MAXCPU * 4. Or just another big number, like > 256. A prerequisite for this idea though is that MAXCPU needs to be fixed to export the SMP value to userland rather than the UP value. For example, this code in amd64/include/param.h: #if defined(SMP) || defined(KLD_MODULE) #define MAXCPU 32 #else #define MAXCPU 1 #endif would need to change so that !_KERNEL is in the conditional. I do think we should avoid using MAXCPU in userland as much as possible and use the existing sysctl for mp_maxid instead to dynamically allocate arrays. Also, I think we should either fix MAXCPU to export the SMP value to userland, or hide it from userland completely. Exporting the UP value is Just Wrong (tm). -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201009271738.19497.jhb>