Date: Sat, 12 Apr 2003 02:12:43 +0300 (EEST) From: Narvi <narvi@haldjas.folklore.ee> To: freebsd-sparc64@freebsd.org Subject: tlb, tsb & ...stuff Message-ID: <20030411224922.B75698-100000@haldjas.folklore.ee>
next in thread | raw e-mail | index | archive | help
ok, I'm a lamer and couldn't think of a nice & spiffy subject line. TLB / TSB statistics: Presently we only get statistics on entries being moved into TSB, with no dtlb/itlb separation. Unless people think this is a bad idea, I'd like to make an option that would expose dTLB/iTLB and related TSB misses as statisics. this would allow you to get Solaris 9 style 'trapstat -t' information. The counters would need to be per-processor. TSB & replacement: >From what I gather (please correct me if I'm wrong!) the present TSB consists of 2K entries, organised into buckets with each bucket containing 4 entries. On replacement/entry we enter into an entry that was empty/invalid or pick one "randomly" based on the lower digits of tick. We try 4 times (for each page size) so up to 16 places get probed before a miss / hit. Making it a 4-way random replacement software managed unified L2 tlb (with slight oddness for multiple pages sizes). It would imho be interesting to support a couple of different and selectable entry indexing policies, say at least: * hashed * skew-associative to cater for various access patterns & tsb lookup loads. Again, if this would be a bad idea, let me know. Usparc3(cu) What will happen there? Do we use any of the large page sizes enough to make one of the large TLB-s cache a large(r) page size?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030411224922.B75698-100000>