Date: Wed, 15 Oct 2003 01:55:02 -0700 (PDT) From: jkoshy@FreeBSD.ORG (Joseph Koshy) To: Bruce M Simpson <bms@spc.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Determining CPU features / cache organization from userland Message-ID: <20031015085502.6FF5416A4BF@hub.freebsd.org> In-Reply-To: Your message of "Mon, 13 Oct 2003 20:32:58 %2B0100." <20031013193258.GB25160@saboteur.dek.spc.org>
index | next in thread | previous in thread | raw e-mail
Hi Bruce,
A few thoughts on your API:
1) Rather than naming the struct's as "l1", "l2" etc, it may be more
orthogonal to use an array of cache entries like so
struct entry { ... } entries[MAX_ENTRIES]; where MAX_ENTRIES would be say,
8.
2) We could pass information back about whether the cache is write-back or
write-through and whether it uses write-allocate. In some CPUs (e.g.
the AMD K6-2) this aspect of the cache is programmable at boot time.
3) Have a bit indicating whether the cache is indexed virtually or physically.
This allows us to describe TLBs and caches using the same descriptor; the
MIPS R4K used virtually addressed L1 caches, IIRC.
4) For caches and TLBs that support variable line/page sizes, we would
be reporting the currently programmed size (the kernel knows this
information) I guess?
The 'type' field of the cache descriptor could be an `u_int32_t' or
`u_int16_t',
allocated out as follows:
kind: tlb/cache/other 2 bits
addressing: virtual/physical/unknown 2 bits
mode: data/instruction/both/unknown 2 bits
distance: L0/L1/L2/whatever 3 bits
on-write-hit: write-back/write-thru/unknown 2 bits
on-write-miss: write-allocate/unknown 2 bits
Another suggestion I have is that the sysctl return:
int n_entries;
struct entry entries[n_entries];
since it isn't clear how many levels of cache and how many kinds
of TLBs are going to be used in the systems of tomorrow.
Regards,
Koshy
<jkoshy@freebsd.org>
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031015085502.6FF5416A4BF>