From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 07:07:02 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FA4D16A4B3 for ; Sat, 11 Oct 2003 07:07:02 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2893B43F75 for ; Sat, 11 Oct 2003 07:07:00 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 95251654B4; Sat, 11 Oct 2003 15:06:58 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 93351-03; Sat, 11 Oct 2003 15:06:57 +0100 (BST) Received: from saboteur.dek.spc.org (lardystuffer.demon.co.uk [212.228.40.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id B72E0654C9; Sat, 11 Oct 2003 15:06:55 +0100 (BST) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 6405F31; Sat, 11 Oct 2003 15:06:51 +0100 (BST) Date: Sat, 11 Oct 2003 15:06:51 +0100 From: Bruce M Simpson To: Peter Jeremy Message-ID: <20031011140651.GA1739@saboteur.dek.spc.org> Mail-Followup-To: Peter Jeremy , Andrew Gallatin , Bruce M Simpson , freebsd-hackers@freebsd.org References: <20031010103640.6F5A216A4BF@hub.freebsd.org> <20031010134400.GE803@saboteur.dek.spc.org> <16263.1019.939450.708832@grasshopper.cs.duke.edu> <20031011035827.GD75796@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> <20031011082711.GB679@saboteur.dek.spc.org> <20031011101231.GH75796@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031011101231.GH75796@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> cc: Andrew Gallatin cc: freebsd-hackers@freebsd.org Subject: Re: Determining CPU features / cache organization from userland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 14:07:02 -0000 On Sat, Oct 11, 2003 at 08:12:31PM +1000, Peter Jeremy wrote: > Out of interest, do any systems other than the big-iron Alpha's use L3 > cache? A quick look at the code suggests that only L2 is coloured. L3 cache is present on many MIPS and Pentium Xeon systems, as well as PowerPC G4. > Do any systems use split L2 (or L3) caches? And how do you define the > wierd micro-instruction cache used in the P4? I believe certain models of MIPS may have split L2. Most L3 caches I believe will be unified. > How do you distinguish between a direct-mapped and fully-associative > cache? (Do any current CPUs have fully-associative caches?) For > set-associative caches, is it worth identifying and reporting the > replacement algorithm (eg random, LRU or pseudo-LRU) Add a sysctl type. enum cachetype { notpresent, direct, setassoc, fullyassoc }. Only look at sets if cache type set accordingly. [TLB] > This is possibly more useful on the RISC CPUs where the TLB is managed > in firmware (eg Alpha PALcode) so TLB misses are expensive. Note that > at least the Alpha has multiple sets of TLB registers for different > mapping types and sizes. The number of registers in each set varies > between different AXP generations (though I think the sets remain the > same). I know a number of individuals and organizations involved with FreeBSD pay very close attention to this, to the point of doing TLB profiling to ensure they don't churn too much in time-critical code, particulary on i386 derived platforms. I think knowledge of TLB geometry is valuable everywhere, but more so in the cases you point out. sparc64 has software-managed TLB. [on non-symmetric SMP processor clock-speeds and cache organisation] > Whether FreeBSD wants to support this market is another issue. We'll build that bridge when we come to it. BMS