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. RobertReceived on Mon Sep 27 2010 - 19:21:31 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:07 UTC