Determining CPU features / cache organization from userland

Bruce M Simpson bms at
Sat Oct 11 07:07:02 PDT 2003

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.

> 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.


More information about the freebsd-hackers mailing list