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>
next in thread | previous in thread | raw e-mail | index | archive | help
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).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?is7vnv$sr1$1>