Date: Sat, 11 Oct 2003 15:06:51 +0100 From: Bruce M Simpson <bms@spc.org> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: freebsd-hackers@freebsd.org Subject: Re: Determining CPU features / cache organization from userland Message-ID: <20031011140651.GA1739@saboteur.dek.spc.org> In-Reply-To: <20031011101231.GH75796@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031011140651.GA1739>