Date: Thu, 02 Jun 2011 14:29:51 +0200 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-current@freebsd.org Subject: Re: [PATCH] Add the infrastructure for supporting an infinite number of CPUs Message-ID: <is7vnv$sr1$1@dough.gmane.org> In-Reply-To: <is7vb4$q79$1@dough.gmane.org> References: <BANLkTi=xgP64i2S=SE1zz-p07b7cTA06Zg@mail.gmail.com> <is7vb4$q79$1@dough.gmane.org>
index | next in thread | previous in thread | raw e-mail
On 02/06/2011 14:23, Ivan Voras wrote: > On 01/06/2011 20:21, 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 > > Hi, > > I'm just wandering: what is the expected overhead of this, compared to > using a simple atomic integer (32-bit on i386, 64-bit on amd64)? I > assume that this will introduce more work, like locking, in > performance-critical code like the scheduler, etc.? The reason why I'm asking is this: http://msdn.microsoft.com/en-us/library/dd405503%28v=vs.85%29.aspx It's not necessarily a good approach, but it does have the benefit of keeping the CPU mask operations atomic... (I don't know if the benefits of this are big enough).home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?is7vnv$sr1$1>