From owner-freebsd-current@FreeBSD.ORG Sun Oct 8 20:44:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEC2316A415 for ; Sun, 8 Oct 2006 20:44:52 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C040543D5D for ; Sun, 8 Oct 2006 20:44:51 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GWfVo-0008HL-7Z for freebsd-current@freebsd.org; Sun, 08 Oct 2006 22:44:40 +0200 Received: from 83-131-108-115.adsl.net.t-com.hr ([83.131.108.115]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 08 Oct 2006 22:44:40 +0200 Received: from ivoras by 83-131-108-115.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 08 Oct 2006 22:44:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Sun, 08 Oct 2006 22:44:26 +0200 Lines: 11 Message-ID: References: <2fd864e0610080423q7ba6bdeal656a223e662a5d@mail.gmail.com> <200610082011.53649.davidxu@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 83-131-108-115.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) In-Reply-To: <200610082011.53649.davidxu@freebsd.org> Sender: news Subject: Re: [PATCH] MAXCPU alterable in kernel config - needs testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2006 20:44:52 -0000 David Xu wrote: > I think MAXCPU should not be great than 32, since we currently define > cpumask_t as an integer which now should be changed to a bitmap and > a group of operations like we did for sigset_t. Maybe there should be an option "MANYCPUS" that wraps current calls that manipulate this int value into calls that operate on a bitmap, so there's no speed loss in machines with low number of CPUs. Also, why not use a 64-bit int on 64-bit platforms for the mask? This will cover at least Niagara 2 by default.