From owner-freebsd-stable@FreeBSD.ORG Tue Apr 13 06:22:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 431171065673 for ; Tue, 13 Apr 2010 06:22:52 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 141298FC17 for ; Tue, 13 Apr 2010 06:22:51 +0000 (UTC) Received: by pwi9 with SMTP id 9so5607108pwi.13 for ; Mon, 12 Apr 2010 23:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:received:message-id:subject:from:to:cc:content-type; bh=XbgXn+Ky6Au6LWLI27LF3ghBS5vdyjXkmZPG+3ckmLA=; b=spc+i8w6hszApk7V08UNRTWGB6woiCm/VTK247UuTJ8TJrxSb5gscTHq2PFY4sXUFU BGOnLMrYJ10qYHLTBtySAbjbsXn08Ex823o7IfvRLaHkZ2tLWTK/fVZyyfy7LG26Bj2F 09pUH75B++bHby5TKurAtujaXLh8tWq8jQ/sc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=CmFuQ1U0E7+/qhSorHDaim6mfeVloAb5w+UOEbGoHHk5s4dcPhm2PVnacWww7xfeQL jo5wA+gJuHltKcP+JMb/Vrkr5o57gF08UomYXwegjxKBuzVJW8tZxaRR+p9tuzLWtFgJ iQKZO/kaiudSFsLWfN+Y9dQRB5LAk8ZqwSD3s= MIME-Version: 1.0 Received: by 10.143.158.20 with HTTP; Mon, 12 Apr 2010 23:22:51 -0700 (PDT) In-Reply-To: <4BC402B7.5000400@modulus.org> References: <20100412.131213.4959786962516027.chat95@mac.com> <4BC402B7.5000400@modulus.org> Date: Tue, 13 Apr 2010 01:22:51 -0500 Received: by 10.142.152.29 with SMTP id z29mr2369126wfd.30.1271139771490; Mon, 12 Apr 2010 23:22:51 -0700 (PDT) Message-ID: From: Alan Cox To: Andrew Snow Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Maho NAKATA , freebsd-stable@freebsd.org Subject: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 06:22:52 -0000 On Tue, Apr 13, 2010 at 12:35 AM, Andrew Snow wrote: > > The statements about the scheduler flipping between cores is also somewhat > false, ULE does the right thing now for long-running computational threads. > > Furthermore, I can't see how a Gflops benchmark which fits in the CPU cache > has anything to do with the memory architecture of the operating system. > > It can. Search the web for descriptions of page coloring. Roughly speaking, if your cache is physically indexed, the way in which the virtual memory system allocates physical pages to virtual addresses can affect whether or not the cache is fully utilized. In a pathological case, those physical pages that your application touches reside in the same part of the cache and consequently you suffer frequent conflict misses. Meanwhile, the other parts of the cache go unused. Page coloring creates a predictable mapping between virtual and physical addresses so that a carefully written application can avoid the pathological case. Our support for superpages has the same effect. Alan