Port-vax archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Does the KA630 have a TB?
>> Yes...but, now, I find that it fails when I remove the TB logging
>> code (which I'd like to remove for performance's sake; it introduces
>> some relatively complex operations into a very heavily used
>> codepath). I've so far been unable to see what it does that makes
>> any difference; I'll have to dig deeper.
> So maybe there is actually some bugs in your code after all. ;-)
What? My code has a _bug_?? That _never_ happens!
>>> Why not cache entries outside main memory, by the way?
>> The main motivation for adding the TB was that I want to experiment
>> with JITting the code to native machine code. [...] This would
>> permit the native machine code for a memory access to be relatively
>> streamlined. "Make the common case fast"....
> But you don't even know it's for the bus adapter until you've gone
> through the PTE translation anyway.
> While once you've done the translation, it's obvious.
True as far as it goes. My thought went more or less like this: I
cache (faster-to-access forms of) PTEs for virtual addresses that map
to main memory, but nothing else. The first lookup for a given page,
yes, is slow, but after that, we hit the TB cache and the JITted code
doesn't need to fail to the slow path; it can go straight to main
memory. For access to devices, I never enter it in the TB, so JITted
code always takes the slow path, which it might as well do anyway.
>>>> I find it interesting that this NetBSD doesn't use TBIS at all.
>>> Agreed. Seems like it would potentially be clever to just do TBIS
>>> when you update one page.
>> True. It may be relevant that NetBSD/vax, 1.4T at least, uses 4K
>> pages in the getpagesize() sense; [...]
> The 4K page is a bit more recent. Back when this was messed around
> with, NetBSD used a 1K page size on VAX.
Well, the 1.4T kernel I'm working with definitely uses 4K pages.
PGSHIFT is 12 and the code has plenty of "8 copies with slightly
different offsets" such as
g = (int *)pv->pv_pte;
if ((pv->pv_attr & (PG_V|PG_M)) != (PG_V|PG_M))
pv->pv_attr |= g[0]|g[1]|g[2]|g[3]|g[4]|g[5]|g[6]|g[7];
or
patch[i] = newpte;
patch[i+1] = newpte+1;
patch[i+2] = newpte+2;
patch[i+3] = newpte+3;
patch[i+4] = newpte+4;
patch[i+5] = newpte+5;
patch[i+6] = newpte+6;
patch[i+7] = newpte+7;
So I guess the codebase I have came from after the switch to 4K.
/~\ 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
Home |
Main Index |
Thread Index |
Old Index