Date: Tue, 13 Apr 2010 01:22:51 -0500 From: Alan Cox <alan.l.cox@gmail.com> To: Andrew Snow <als@modulus.org> Cc: Maho NAKATA <chat95@mac.com>, freebsd-stable@freebsd.org Subject: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920 Message-ID: <v2gca3526251004122322i709c523ct4f93bcf75a778a8e@mail.gmail.com> In-Reply-To: <4BC402B7.5000400@modulus.org> References: <20100412.131213.4959786962516027.chat95@mac.com> <h2yca3526251004122230l909bc93ey916d7fe0dd24fd33@mail.gmail.com> <4BC402B7.5000400@modulus.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 13, 2010 at 12:35 AM, Andrew Snow <als@modulus.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v2gca3526251004122322i709c523ct4f93bcf75a778a8e>