Date: Sat, 11 Oct 2003 09:27:11 +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: <20031011082711.GB679@saboteur.dek.spc.org> In-Reply-To: <20031011035827.GD75796@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Oct 11, 2003 at 01:58:27PM +1000, Peter Jeremy wrote: > >If you do this, it may make sense to use the same names as MacOSX. > > What if your hardware has different linesizes for different caches? I noticed whilst peering in Apple Developer Notes that G5 has 128 byte cache line size, and this screws up mutexes bigtime. (!!) OS X definitions considered too PowerPC centric. I think the best way to handle all cases is thus:- - Support 3 levels of cache. - Each level may be unified or split between code and data not-quite-Von-Neumann-style. - Allow explicit retrieval of this info keyed on the cache you're interested in. This means: hw.cache.lN.(linesize|lines|sets) - 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). - Assume that all CPUs have identical characteristics in an SMP system. Trying to assume otherwise is pointless. People should be using matched chips anyway. BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031011082711.GB679>