From owner-freebsd-current@FreeBSD.ORG  Thu Jun  2 12:30:09 2011
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 6873F106566B
	for <freebsd-current@freebsd.org>; Thu,  2 Jun 2011 12:30:09 +0000 (UTC)
	(envelope-from freebsd-current@m.gmane.org)
Received: from lo.gmane.org (lo.gmane.org [80.91.229.12])
	by mx1.freebsd.org (Postfix) with ESMTP id 1E1F68FC13
	for <freebsd-current@freebsd.org>; Thu,  2 Jun 2011 12:30:08 +0000 (UTC)
Received: from list by lo.gmane.org with local (Exim 4.69)
	(envelope-from <freebsd-current@m.gmane.org>) id 1QS72J-0004MJ-Te
	for freebsd-current@freebsd.org; Thu, 02 Jun 2011 14:30:03 +0200
Received: from lara.cc.fer.hr ([161.53.72.113])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <freebsd-current@freebsd.org>; Thu, 02 Jun 2011 14:30:03 +0200
Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <freebsd-current@freebsd.org>; Thu, 02 Jun 2011 14:30:03 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: freebsd-current@freebsd.org
From: Ivan Voras <ivoras@freebsd.org>
Date: Thu, 02 Jun 2011 14:29:51 +0200
Lines: 25
Message-ID: <is7vnv$sr1$1@dough.gmane.org>
References: <BANLkTi=xgP64i2S=SE1zz-p07b7cTA06Zg@mail.gmail.com>
	<is7vb4$q79$1@dough.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr
User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US;
	rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6
In-Reply-To: <is7vb4$q79$1@dough.gmane.org>
X-Enigmail-Version: 1.1.2
Subject: Re: [PATCH] Add the infrastructure for supporting an infinite number
 of CPUs
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jun 2011 12:30:09 -0000

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).