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>