Im about to start the process of creating a cpuid_t and peppering it around the source tree.
Too many odd places use u_char as a cpuid and it's going to be limiting. -a On 27 May 2014 21:11, Jia-Shiun Li <jiash...@gmail.com> wrote: > On Sat, May 24, 2014 at 6:38 PM, Tim Bishop <tim-li...@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. > > *: E.g. IBM System x3950 X6 > > > -Jia-Shiun. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
