[PATCH] Add the infrastructure for supporting an infinite number of CPUs

[Jack Vogel]

Awesome, glad to see this happening :)

Jack


On Wed, Jun 1, 2011 at 11:21 AM, Attilio Rao <attilio at freebsd.org> 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"
>