From owner-freebsd-current@FreeBSD.ORG Mon Jul 26 10:09:35 2010 Return-Path: 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 46DEB1065674 for ; Mon, 26 Jul 2010 10:09:35 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by mx1.freebsd.org (Postfix) with ESMTP id CDDA88FC22 for ; Mon, 26 Jul 2010 10:09:34 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c211-30-160-13.belrs4.nsw.optusnet.com.au [211.30.160.13]) by mail18.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o6QA9Vkv014049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jul 2010 20:09:32 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id o6QA9Sjp008858; Mon, 26 Jul 2010 20:09:28 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id o6QA9R4G008857; Mon, 26 Jul 2010 20:09:27 +1000 (EST) (envelope-from peter) Date: Mon, 26 Jul 2010 20:09:27 +1000 From: Peter Jeremy To: Sean Bruno Message-ID: <20100726100927.GA6844@server.vk2pj.dyndns.org> References: <20100722213836.GH15227@martini.nu> <1279836216.2456.14.camel@localhost.localdomain> <20100723003611.GA66678@martini.nu> <7573B69C-3C37-449A-A27F-5B0B2ED84757@mac.com> <1280090933.14823.2.camel@localhost.localdomain> <20100725205730.GG22295@deviant.kiev.zoral.com.ua> <1280096002.14823.24.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: <1280096002.14823.24.camel@localhost.localdomain> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Kostik Belousov , "sbruno@freebsd.org" , freebsd-current Subject: Re: [patch and review please] 64 CPU Support 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: Mon, 26 Jul 2010 10:09:35 -0000 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Jul-25 15:13:22 -0700, Sean Bruno wrote: >On Sun, 2010-07-25 at 13:57 -0700, Kostik Belousov wrote: >> Very low-priority comment (I looked at the patch at the time it was >> posted to stable@). Nice thing about the patch is that it presumably >> identifies all the places that depend on the wideness of the cpu >> mask. Would it make sense to abstract the cpumask operations with >> some macros to not repeat the search for the places when 64 will >> be too narrow again ? > >What do you mean? Can you give me a quick example? =20 I can easily buy a machine with 128 CPU threads today (maybe 256). At some point, FreeBSD is going to need to be able to support boxes that contain too many CPUs to hold the CPU mask in a long. Your patch pulls (1 << i) into a macro cputomask(i) but still assumes that a CPU mask is representable as an integral type. Since you've gone to the effort of identifying all the places where this cpumask operations are referenced, would it not make more sense to replace them all with more generic functions to simplify future support for more than 64 CPUs. As a concrete example, instead of: CPU_FOREACH(i) { - if (((1 << i) & map) !=3D 0) + if ((cputomask(i) & map) !=3D 0) ncpus++; } use something like: CPU_FOREACH(i) { if (cpu_testmask(&map, i)) ncpus++; } And instead of: pcpu->pc_cpuid =3D cpuid; - pcpu->pc_cpumask =3D 1 << cpuid; + pcpu->pc_cpumask =3D cputomask(cpuid); cpuid_to_pcpu[cpuid] =3D pcpu; something like: pcpu->pc_cpuid =3D cpuid; cpu_setmask(&pcpu->pc_cpumask, cpuid); cpuid_to_pcpu[cpuid] =3D pcpu; Obviously, expanding the atomic operations beyond long is non-trivial but I suspect that the requirement is only that each individual bit is atomic between the "master" CPU and the relevant other CPU - which means that the atomic operations can be carried out independently on a suitable subset (int or long) of the complete mask. --=20 Peter Jeremy --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkxNXtcACgkQ/opHv/APuIeKcgCgrXXhq46V4DKkLGvOWH2t4Oyk Bp0An31KPvptO44GDUpnb7TAg+EyrKIY =GOXJ -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK--