From owner-freebsd-current@FreeBSD.ORG Mon Oct 9 07:43:57 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 AD40916A403 for ; Mon, 9 Oct 2006 07:43:57 +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 8FD2743D77 for ; Mon, 9 Oct 2006 07:43:49 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GWpnC-00026J-1d for freebsd-current@freebsd.org; Mon, 09 Oct 2006 09:43:18 +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 ; Mon, 09 Oct 2006 09:43:18 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Oct 2006 09:43:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Mon, 09 Oct 2006 09:41:56 +0200 Lines: 18 Message-ID: References: <2fd864e0610080423q7ba6bdeal656a223e662a5d@mail.gmail.com> <2006 10082011.53649.davidxu@freebsd.org> <20061008135031.G83537@demos.bsdclusters.com> <4529667D.8070108@fer.hr> <20061008155350.L29803@demos.bsdclusters.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.4 (X11/20060625) In-Reply-To: <20061008155350.L29803@demos.bsdclusters.com> 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: Mon, 09 Oct 2006 07:43:57 -0000 Kip Macy wrote: >> Any word on how will they handle migration of threads across sockets (or >> will it be OS's job)? Judging from T1 architecture, I think such event >> would create a very large performance penalty, but I'm not an expert. > > It is the job of the OS to take locality into account in thread > scheduling. Moving between chips You'll just lose the L2 cache locality > just as you would on a normal SMP. I'm reading about the architecture now; it seems 8 threads of a core are divided into two thread groups (each of which has its own ALU) and there's a hierarchy of "closeness" in terms of moving threads between execution units: 1. inside of thread group (instantaneous) 2. between thread groups 3. between cores 4. between CPUs/sockets