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
<[EMAIL PROTECTED]>
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
