On Thu, 15 Oct 1998 email@example.com wrote:
> The performance hit will come into the game as soon as one tries to
> build a generic kernel for both R3000 and R4000. The R3000 PID and the
> R4000 ASID mechanism are slightly different and the simple approach
> to fix that is to use global variables. Which affects both your version
> and the current version.
We are going to provide support for building generic kernels in the near
future if somebody who holds r4k will help us and will try our patches
on a r4k box. I think the best time to start is when r3k will be synced
with the main branch. Perhaps, Harald may answer when it might occur.
> Which I want to avoid because in worst case that means we'll have to eat
> a latency of over 1400ns per cache line to fetch from memory. This number
> is measured on a R4000SC with 100Mhz. That is enough to show up right
> away on the context switch times which now look fairly nice as long as we
> don't have to swallow cache faults.
Perhaps, we may use global vars in most cases and patch code at bootup
for critical ones.
> > So, I don't understand why idea of using all free upper bits as asid
> > extension is bad -- same time it increases security it allows to
> > increment
> > version automatically when asid overflow occurs.
> No. It gives us a view bits more, but way not enough. The mmu context code
> we have has been copied almost unmodified from the Alpha which from EV5 on
> also supports ASNs. The big difference between the Alpha and the MIPS
> implementation is that on the Alpha the type ``unsigned long'' which is
> used for counting ASN and ASN version number has 64 bit. Assuming UP and
> the worst case which is 2^7 ASNs they still have 2^57 versions before a
> version overflow will happen. In other words, assuming 1,000,000 context
> switches per second they still have almost 600,000 years before an ASN
> collission may occur.
> The MIPS implementation does worse, especially for the R3000 where waste the
> lowest 6 bits which effectivly truncates our ASID (or PID) to 26 bits.
> Assuming just 100,000 context switches we'll wrap around after just a bit
> more than 11 minutes. I think we can do more than 100,000 context switches
> per second on a reasonable R3000 system.
As I understand the only place where change the version is in
get_new_mmu_context(). Thus, if the version overflows we may create a new
process which will share its address space with other due to the same
ASID and varsion pair. Am I right ?
> Btw, is any of the R3000 machines stable enough to run lmbench? I'm
> interested to get results, best the raw result file from
> lmbench/results/mips-linux/. Reminds me to run lmbench on my RS3230.
Ok. I will try to run lmbench while Vladimir will think about your ideas :-)