From owner-freebsd-current@FreeBSD.ORG Thu Jun 2 13:02:46 2011 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 874E0106566C for ; Thu, 2 Jun 2011 13:02:46 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2516D8FC12 for ; Thu, 2 Jun 2011 13:02:45 +0000 (UTC) Received: by vws18 with SMTP id 18so839679vws.13 for ; Thu, 02 Jun 2011 06:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=//op7Z3e5E8EjSyDjsT6hHVmlMMLnnnBM1uzq+Ee3BA=; b=H6EHGXT7w1XvKfRNJ9CtE0uOlV1rW8eq94lW4S2EZeT7IXRREeiIlz1ROLClSUCkV6 m6IXhiMHMU23Bnoo90p1bhNEbx0qnnWqgm7jMGIUrgS1mxrFglKkpEAP3UPpSwdJKH+i DnbB49AtNQgd+XjEFYne30oUAJ2YxSP78NkW4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=jAKOFKK8d8dUe9kQfyMGnRtB0mPtEZnVjLTjHHwzRLHkQW767R7KQUEXtjRd2Ae2ov hsDcJPZcBTMDAYNIZxRt3mvhsN6sYgp4h8bFab3EbWsS1k1/0VfR/tTuzPqbxvgEzdJH JRZewLrDSDGu6r/s/CQ1v1qpTFvMiY7pN+6wg= MIME-Version: 1.0 Received: by 10.52.175.137 with SMTP id ca9mr264587vdc.194.1307019765300; Thu, 02 Jun 2011 06:02:45 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.220.178.65 with HTTP; Thu, 2 Jun 2011 06:02:44 -0700 (PDT) In-Reply-To: References: Date: Thu, 2 Jun 2011 09:02:44 -0400 X-Google-Sender-Auth: xFbTYcwaNm9tOE-NY5sOV-a4ebo Message-ID: From: Attilio Rao To: Ivan Voras Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 13:02:46 -0000 2011/6/2 Ivan Voras : > 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.? Once the cleanup of this code is finished (read one of the point of my patches) only some global variables will still be needed to be used as cpuset_t whole operation (all_cpus, for example) and they are all used rarely enough that should be negligible. FreeBSD right now uses the cpuset_t mostly for these things: - pcpu masks (pc_cpumask, pc_other_cpus) - pmap pm_active - global masks for tracking online CPU, HTT, etc. The second type is just accessed on a bit basis, so it doesn't apply. The first one will be optimized in the next round of changes. As said, just the third type will remain and really is a minor factor in performance. > 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). Well, it is just actually bypassing the problem and also I'm not entirely sure it is a great idea from other point of views. In particular, I've never seen so far a 64 cpus system offering homogeinity among them, I wonder how you can consider a single schedule entity something like 8 x 4 x 4(htt)? Attilio -- Peace can only be achieved by understanding - A. Einstein