Re: Does the KA630 have a TB?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> Should not matter.  You should be able to use any size TB.

If the OS uses it correctly, yes.  If.

>> I suspect [the TB's] size matters because that NetBSD version
>> actually does run on the KA630, without the TBIA/TBIS usage, whereas
>> when provided with an unlimited-size TB [...] it fails - and I've
>> added enough debugging code to be confident that it's failing
>> because the TB holds stale entries.
> I think you are wrong here.

Possibly.  See below for more.

>>> And I have a hard time thinking that NetBSD would depend on any
>>> specific size of the TB.
>> I don't think it does, not on any specific size.  I think it, that
>> version, just depends on its size and replacement policy being such
>> that that stale entries get replaced before they cause trouble.
> That would be crazy and broken.

Yes.  I don't for a moment think it _deliberately_ depends on that.  I
think someone just missed writing the relevant mtpr() calls and it took
a while for anyone to notice, presumably because all the tests anyone
did were on systems (whether hardware or simulated) which either lacked
a TB or provided one which ended up flushing stale entries before they
caused trouble.  Ragge added some TBIA calls in April 2000; see rev
1.78 of the VAX pmap.c.

> So, I seriously doubt that there is even some hidden dependency on
> some size.  And the actual size is rather different on different
> VAXen that NetBSD runs on.

Certainly.  But how many different models has 1.4T/vax been tested on?
Personally, don't think I've ever tried it on anything but a uVAX2,
which Antonio Carlini said has a _tiny_ TB (8 bytes).

> But basically, we're talking about the TB now. It's automatically
> populated, but in some situations software needs to explicitly flush
> it.

Right.  NetBSD 1.4T fails to flush it in at least some circumstances
when it should.  Read pmap_enter() in -current and in 1.4T and note the
lack of a TBIA in some codepaths in the 1.4T version.  (There are a few
other pmap calls which are affected as well.)

> But from what you are saying, it sounds like you are hitting problems
> where none of those situations are going on, right?

It _appears_, from what little I've found, to be a case of taking a
write fault, updating the pmap, failing to invalidate, and then
returning to userland.  (I suspect the write fault is may be COW case,
but I haven't done the digging to be certain.  I am inclined to doubt
it's just a write-tracking fault, because the PFN changes.)

> So, my thinking are context switches, which also affect the TB, since
> you get completely new page tables.  [...] LDPCTX implicitly should
> force a TB flush.

Yes.  The third-last thing my ldpctx implementation does is to clear
the whole TB.  (The second-last and last are pushing the PC and PSL on
the (new) stack in preparation for REI.)

> So my question to you now is: are you flushing the TB when that
> instruction is executed?

Yes.  Also, there is no ldpctx (or svpctx, not that that's very
relevant) happening between the TB entry being created and it later
being discovered to be stale - I did a run with tracing cranked all the
way up, so it logged _everything_.

I've now modified my NetBSD/1.4T enough that it appears to work with
the large TB.  I just added more uses of the TBIA, based mostly on the
delta between sys/arch/vax/vax/pmap.c 1.77 and 1.78, as modified by the
delta from 1.84 to 1.85; I need to grab a copy of that file from
-current and make sure I have appropriate analogs of all the TBIA/TBIS
calls it does.

I am pleased to find that it appears to be relatively effective.  I
just booted my emulator single-user and force-fscked its disk.  After
that, printing TB stats gives

Translation buffer statistics:
Hits 792967524 misses 3419573 (99.5706%), enters 3089291
Level 1: 6/4096 (0.146484%)
Level 2: 72/12288 (0.585938%)
Clears: all 27910, one 0

The difference between misses and enters corresponds to attempted
accesses that don't reach RAM, either because they fail or because they
go to devices or other things outside RAM - my TB doesn't cache
anything that doesn't point to main memory.  (The "Level 1" and "Level
2" numbers are current-state info, not long-term statistics, so they're
pretty meaningless for purposes of this email.)

I find it interesting that this NetBSD doesn't use TBIS at all.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B