[blog] MMU mini-series (2/4)

[gregory]

Take the picture of my post. All virtual addresses that are not mapped in user memory space are illegal, roughly 3.9GB.

If you break the game there is high probability that you will access forbidden address that will generate a TLB miss.

If the game doesn't install a TLB miss handler (PS2 kernel doesn't provide a default one) it will badly crash. Even if the game install an handler, recompiler can't support it so it will break.

Actually there is 2 class of TLB misses.
1/ expected TLB miss, slow but can be handled
2/ unexpected TLB miss, just killer

[willkuer]

Maybe another small question....
Now you know exactly how all of this works for the ps2 MMU... If you write a program like pcsx2 do you need to know how windows/linux handles this as well? Or is the compiler doing all the work for you? I would guess if you control caching you could optimize the code a lot...

[ssakash]

I would guess if you control caching you could optimize the code a lot...

by controlling cache do you mean, having the use of cache take place only when the data has temporal locality ? is that even possible.

[gregory]

Which cache? The x86 cache? Or the ps2 cache which is not emulated.

There is some special instruction to control x86 cache but generally the hardware handle it well enough. However you can code in a way that cache eviction will be reduced which in turn greatly improve perf

[ssakash]

Meant the x86 cache , could you explain about the special instruction on controlling the x86 cache.

[willkuer]

As I understood ps2 software directly sets the memory access (these three modes, uncached, cached, accelerated). It is not the bios that decides which one to use.
How does x86 software (using whatever OS) handle memory access? How does the x86-cpu know that it should cache some data in the cache and not evaluate it uncached because it will never be used again? Does the OS handle the access mode or the program? I think you can give a volatile keyword in C code. Does this mean that the corresponding data is evaluated uncached?

[gregory]

Actually control is maybe the wrong word. Anyway,

You can use
1/ prefetch instruction (to preload instruction in instruction cache)
2/ uses SSE/AVX NT instruction. NT stand for non-temporal, which basically mean => no plan to use it soon, don't bother with the cache
3/ volatile keyword in C. It means the value is volatile (can be updated by the HW) so CPU mustn't cache it.

I don't know how the X86 handle cached/uncached memory but I guess it must be rather similar. The OS set some flags on the MMU, MMU will tell the processor to cache or not the data.

As I understood ps2 software directly sets the memory access ( ... ) It is not the bios that decides which one to use.

What is the bios for you? What is the PS2 bios for you ?

[willkuer]

Oh wow... I just read a bit about volatile and have real concerns about the multi-threaded applications I wrote... Using that knowledge I don't even know how they worked... Obviously the compiler was smart enough to see my stupidness and solved all errors...

I thought this MMU stuff was about optimization... but this volatile keyword is much more.


Now I think I understand the whole concept sufficiently enough to open no further questions. Thank you very much.


Just another small question about something different ;D. What about L1/L2/L3 cache? Does the ps2 have more than one level? How does the MMU know to which level to put the memory? Are there even more flags or is the mmu smart enough by itself to coordinate these? I would guess transfering data from one cache to another is probably similarly expensive as from the memory to the cache?

Thank you again for this blog entries/mini series and continuous answering n00b questions.

[Blyss Sarania]

Just another small question about something different ;D. What about L1/L2/L3 cache? Does the ps2 have more than one level? How does the MMU know to which level to put the memory? Are there even more flags or is the mmu smart enough by itself to coordinate these? I would guess transfering data from one cache to another is probably similarly expensive as from the memory to the cache?

EE cache:

To feed the execution units with instructions and data, there is a 16 KB two-way set associative instruction cache, an 8 KB two-way set associative non blocking data cache and a 16 KB scratchpad RAM. Both the instruction and data caches are virtually indexed and physically tagged while the scratchpad RAM exists in a separate memory space. A combined 48 double entry instruction and data translation lookaside buffer is provided for translating virtual addresses. Branch prediction is achieved by a 64-entry branch target address cache and a branch history table that is integrated into the instruction cache. The branch mispredict penalty is three cycles due to the short six stage pipeline.

FWIW you'll also notice in the PCSX2 settings that you can enable/disable EE cache(which is OFF by default). Enabling is required for like a couple games, otherwise it's a decent performance hit.

[willkuer]

Enabling is required for like a couple games, otherwise it's a decent performance hit.

That's again quite funny. Normally I would say that if you replace all cached stuff by volatile stuff it will still work but will be slower while enabling caching can help increasing performance... You are saying more or less the contrary.
That the whole system is slower if cache is enabled sounds at least possible to me if there is some overhead in implementing the cache. That disabling the cache breaks games on the other hand sounds completely strange.