Hi,

Abhishek Bhattacharjee wrote:
Hi Gavin

Thanks a ton for your detailed response! I was getting at exactly the issue of
> whether it is possible to have a TLB miss while already servicing a 
user-level miss.
>
I'm actually a bit surprised that all the TSB and hash-table are maintained in
> physical memory. I had somehow assumed that due to its size, some portion of
> it would be virtually allocated by the VM system.

Inidvidual TSBs are not all that big, but the main hashes (1 user, 1 kernel)
are huge and are not allocated in one physically contiguous hunk.  It would take
some time to work out the exact rules, but it is a combination of
virtually allocated and updated and physically accessed during miss
handling.

I had another question, one which might be rather vague I'm afraid. I have
> been running some experiments with the Simics infrastructure (which models
and Ultrasparc III Cu running Solaris 10) and have been tracking TLB miss
> patterns for a variety of workloads. Now, when there is a TLB miss, I am
> seeing that the OS gets an interrupt and services the miss, after which
> it inserts the appropriate entry into the TLB. What is puzzling me is
> that the OS also seems to be removing and adding TLB entries in the
> fully-associative 16-entry DTLB without actually experiencing a TLB miss.
I am at a loss as to why the OS might want to tamper with this TLB
> without incurring a previous miss...so my question is, are there instances
> when the OS removes and adds TLB entries without and initial TLB miss?

So I misled you a bit there.  Some (newer) systems access the TSB with
all-physical accesses.  The older sun4u systems, including that
which Simics is presenting, use virtual accesses and to avoid
further TLB misses during processing of an initial miss we load
locked entries into the t16 for the TSBs.  TSBs are changed when we
context switch etc, so we will load new locked translations
at context switch events.  See LOAD_TSBTTE, MAKE_TSBREG etc.

Gavin
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to