On Sat, Oct 11, 2003 at 09:27:11AM +0100, Bruce M Simpson wrote: >OS X definitions considered too PowerPC centric. I think the best way >to handle all cases is thus:- > > - Support 3 levels of cache.
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. > - Each level may be unified or split between code and data > not-quite-Von-Neumann-style. Do any systems use split L2 (or L3) caches? And how do you define the wierd micro-instruction cache used in the P4? > - Allow explicit retrieval of this info keyed on the cache you're > interested in. This means: hw.cache.lN.(linesize|lines|sets) 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) > - Do similar for the TLB insofar as we can return information about > the chip's TLB. I know for example from talking to peter@ that > the Opteron is quite a different beast (ASNs, flush filter, etc). 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). > - Assume that all CPUs have identical characteristics in an SMP system. > Trying to assume otherwise is pointless. People should be using matched > chips anyway. HP AlphaServer ES47 (and ES45 from memory) allow different speed CPUs in an SMP system. Some of the high-end SPARCservers probably do as well. This probably does make sense when you're talking about a system which might be expanded over its lifetime - and the slow CPUs that came with the system initially might no longer be available but you need more CPUs and can't justify replacing the existing ones. Whether FreeBSD wants to support this market is another issue. Peter _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
