From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 22 17:33:46 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17DA61065675 for ; Wed, 22 Sep 2010 17:33:46 +0000 (UTC) (envelope-from curtis.penner2@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id DC1D78FC0A for ; Wed, 22 Sep 2010 17:33:45 +0000 (UTC) Received: by pxi17 with SMTP id 17so269246pxi.13 for ; Wed, 22 Sep 2010 10:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=SNI5Ek1jZa/aTYeV0c8LtOphXj1AvFIGmsuDQyObDLA=; b=NgwntF9UWydc9YbprhJFlu11gcpWleS7qSNMX8sSYKGVhA2WWlN9Ac5rThMDXZBNT7 YHI854WQjdIke1ki/zA8mvrCgVxeAhRyXGkifK47qehs8yUVRLVMPFkvizChtHIEsYwh 3M4uxlD2CxMz8tFiKaCEUX/UeVIbqCoKuK1W0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=E5Cn3e7eYHTJzP7tytpnQiqHnTYGx7G20vkGhUgo5tWkW8c9Cmj1XQvwPfkqfgUuh6 O68ePfy1ht8f6bHa+eg1jf9Z1eT42LYHYiIOE93j1yPmBJwj/W8vVyKYRZw+WQ8Ebv3l 2odHTmLoKjoR03h6hMAY1FqaHuwQ4uxQqtsmc= Received: by 10.114.152.6 with SMTP id z6mr530865wad.151.1285175311540; Wed, 22 Sep 2010 10:08:31 -0700 (PDT) Received: from [192.168.77.141] (64-71-25-34.static.wiline.com [64.71.25.34]) by mx.google.com with ESMTPS id o17sm17938183wal.21.2010.09.22.10.08.28 (version=SSLv3 cipher=RC4-MD5); Wed, 22 Sep 2010 10:08:29 -0700 (PDT) Message-ID: <4C9A380E.7070807@gmail.com> Date: Wed, 22 Sep 2010 10:08:30 -0700 From: Curtis Penner User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4C99DC48.1020208@FreeBSD.org> <201009220937.13155.jhb@freebsd.org> In-Reply-To: <201009220937.13155.jhb@freebsd.org> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Bumping MAXCPU on amd64? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 17:33:46 -0000 MAXCPU at 32 has been good in the 32bit days. Soon there will be (if not already) systems that will have 16cores/socket or more, and motherboards that have 4 sockets or more. Combining this with hyper-threading, you have gone significantly beyond the limits of feasible server. Bumping the number now is not feasible. But in release 9+ or 10, this number could be bumped to something in the order of 1024 or more. This will not be easy as there are considerable performance and compatibility problems. But with Moore's law it will happen, and freeBSD will need to adapt to stay relevant. Curtis Penner On 09/22/2010 06:37 AM, John Baldwin wrote: > On Wednesday, September 22, 2010 6:36:56 am Maxim Sobolev wrote: > >> Hi, >> >> Is there any reason to keep MAXCPU at 16 in the default kernel config? >> There are quite few servers on the market today that have 24 or even 32 >> physical cores. With hyper-threading this can even go as high as 48 or >> 64 virtual cpus. People who buy such hardware might get very >> disappointed finding out that the FreeBSD is not going to use such >> hardware to its full potential. >> >> Does anybody object if I'd bump MAXCPU to 32, which is still low but >> might me more reasonable default these days, or at least make it an >> kernel configuration option documented in the NOTES? >> > ? > > % grep MAXCPU ~/work/freebsd/svn/head/sys/amd64/include/param.h > #define MAXCPU 32 > #define MAXCPU 1 > > In fact: > > % grep MAXCPU ~/work/freebsd/svn/stable/8/sys/amd64/include/param.h > #define MAXCPU 32 > #define MAXCPU 1 > > Unfortunately this can't be MFC'd to 7 as it would destroy the ABI for > existing klds. > >