Attilio, AWESOME! to say the least, but I am sure there is a LOT more to be said. Thank YOU! On Wed, Jun 01, 2011 at 02:21:30PM -0400, Attilio Rao wrote: > Current maximum number of CPUs supported by the FreeBSD kernel is 32. > That number cames from indirectly by the fact that we have a cpumask_t > type, representing a mask of CPUs, which is an unsigned int right now. > I then made a patch that removes the cpumask_t type and uses cpuset_t > type for characterizing a generic mask of CPUs: > http://www.freebsd.org/~attilio/largeSMP/largeSMP-patchset-beta-0.diff > > This is part of a bigger effort which brought to serveral smaller > commits along the way, in order to fix some edge cases. > > Things to pay attention at: > - Userland and kerneland cpuset_t size can be different, thus when > accessing to a kernel cpuset_t object from userland (via kvm_read() > for example) a pattern similar to what pmccontrol does, in this patch, > should be followed > - There are some cpuset_t object in pcpu representing curcpu mask and > !curcpu mask. With transition from cpumask_t to cpuset_t they become > inefficient and not really useful. The next weeks I'll focus on > removing them and make a smarter usage of the cpuset_t interface. > Additively, please note that right now I clobbered pcpu accesses > under scheduler pinnings, because it is possible more than a single > atomic operation is needed for accessing a cpuset_t. When the cleanup > happens those pinnings will go away. > - I had to introduce, among the other things, functions for > representing cpuset_t object in "visual" way, thus > cpusetobj_strprint() and cpusetobj_strscan(). I got the desired format > from what Linux already does, so that someone may be already used to > it. Anyway strings will be represented as a serie of long, hexadecimal > long words, all separated by ", ". The left-most represents the higher > word, following natural bits representation. > - I used cpusetobj_strscan() for implementing KTR_CPUMASK in a way it > supports cpuset_t. Change the kernel config appropriately. > - No MAXCPU has been bumped in the patch, but I encourage you to do so > with your own kernel configurations. > > I really need to commit this patch before code slush happens, thus I > plan to commit it on June 7th, if no one reports bugs or can make good > point on his reviews. Please note that the patch has been greatly > tested and reviewed on all FreeBSD tier-1 and tier-2 architectures. > Anyway more testing and reviews are welcome to happen. > > Thanks, > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" -- "Unity can only be manifested by the Binary. Unity itself and the idea of Unity are already two." -- Buddha Regards, (jhell) Jason Hellenthal
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:14 UTC