Re: Processor cores not properly detected/activated?

On Wednesday, May 28, 2014 1:51:28 pm Adrian Chadd wrote:
> On 28 May 2014 06:56, John Baldwin <jhb_at_freebsd.org> wrote:
> 
> 
> > Userland cpusets only default to 128 (CPU_MAXSIZE in <sys/_cpuset.h>).
> > Changing MAXCPU to even 128 is unfortunately a potential KBI change since it
> > changes the size of 'cpuset_t'.  We can certainly bump these in HEAD for 11,
> > but we might not be able to MFC them without introducing ABI breakage.
> > (The cpuset APIs do allow the size of cpuset_t to change as the size is
> > encoded in the API calls, so there is that, it's more that if some public
> > structure embeds a cpuset_t in the kernel that we would have problems.  I
> > thought 'struct pcpu' did, but it does not.)
> >
> > Hmm, smp_rendezvous() accepts a cpuset_t as its first argument (and is a
> > public symbol used by kernel modules such as dtrace).  'struct rmlock' also
> > embeds a cpuset_t.  So, I think we can't bump cpuset_t without breaking
> > the KBI.  We can bump it in HEAD however.  (Note, if re_at_ signed off, we could
> > perhaps merge to 10, but we tend to be very hesitant about breaking the KBI.)
> > One thing we could do safely is bump the userland cpuset size to 256 in 10.
> > It's really only MAXCPU that is problematic.
> >
> > In particular, I propose we bump the userland cpuset_t size to 256 now (and
> > go ahead and merge that to 10).  In HEAD only we can bump MAXCPU for amd64
> > to 256.
> 
> Since 11 is going to be around for a few years, can we experiment
> bumping it up to something compute-cluster-computer-sized just to get
> it over with? Something stupid, like 4096 or something?

It costs wired memory to increase it for the kernel.  The userland set size
can be increased rather arbitrarily, so we don't need to make it but so large
as it is easy to bump later (even with a branch).

-- 
John Baldwin