Date: Wed, 1 Jun 2011 12:46:45 -0700 From: Jack Vogel <jfvogel@gmail.com> To: Attilio Rao <attilio@freebsd.org> Cc: Nick Esborn <nick@desert.net>, Marius Strobl <marius@freebsd.org>, freebsd-current@freebsd.org, Sergey Kandaurov <pluknet@freebsd.org>, Sean Bruno <seanbru@yahoo-inc.com> Subject: Re: [PATCH] Add the infrastructure for supporting an infinite number of CPUs Message-ID: <BANLkTineBRD57Z_b3ArbvRrqS%2BKAbXiYSQ@mail.gmail.com> In-Reply-To: <BANLkTi=xgP64i2S=SE1zz-p07b7cTA06Zg@mail.gmail.com> References: <BANLkTi=xgP64i2S=SE1zz-p07b7cTA06Zg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Awesome, glad to see this happening :) Jack On Wed, Jun 1, 2011 at 11:21 AM, Attilio Rao <attilio@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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTineBRD57Z_b3ArbvRrqS%2BKAbXiYSQ>