Date: Wed, 28 May 2014 09:56:27 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: Attilio Rao <attilio@freebsd.org>, Alan Somers <asomers@freebsd.org>, Jia-Shiun Li <jiashiun@gmail.com>, Tim Bishop <tim-lists@bishnet.net> Subject: Re: Processor cores not properly detected/activated? Message-ID: <201405280956.27800.jhb@freebsd.org> In-Reply-To: <CAHNYxxPAqrRcJyxY8ZDnL87FdRAUxBL522nAAEQpA19uByYE2w@mail.gmail.com> References: <20140524014713.GF13462@carrick-users.bishnet.net> <20140524103835.GI13462@carrick-users.bishnet.net> <CAHNYxxPAqrRcJyxY8ZDnL87FdRAUxBL522nAAEQpA19uByYE2w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, May 28, 2014 12:11:30 am Jia-Shiun Li wrote: > On Sat, May 24, 2014 at 6:38 PM, Tim Bishop <tim-lists@bishnet.net> wrote: > > On Fri, May 23, 2014 at 09:03:12PM -0600, Alan Somers wrote: > >> Yeah, I think so. It seems like a GENERIC kernel ought to be able to > >> handle the biggest commonly available quad socket systems. Anything > >> with more than 4 sockets, though, is probably too exotic to deserve > >> such special treatment. > > > > I submitted a PR to that effect: > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=190169 > > > > Thanks again for your help. > > > > Tim. > > > > Hi, > > I read in the follow-up of the PR that current hard limit is 256. > Currently available systems* can already push usage up to 240. IVB-EX > aka Xeon E7v2 supports 8-socket * 15-core * 2-thread. Expect something > to break 256 in less than a year I think. X2APIC support will be > required then. In theory it is already possible to build larger > systems with custom glue logic, but I am not aware of any. 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@ 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. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201405280956.27800.jhb>