| stekern | under Linux, can several different virtual addresses map into one physical address? | 09:11 |
|---|---|---|
| Xark | stekern: I would sure think so (e.g. with a read only mapping). | 09:20 |
| stekern | Xark: hmm, bummer... can you give a more concrete example? | 09:26 |
| stekern | I'm asking because I want to know what countermeasures are needed to handle aliasing with a virtually indexed, physically tagged cache | 09:28 |
| Xark | Yeah. I assume you have purused this (but doesn't seem to go into too much detail) -> http://www.makelinux.net/ldd3/chp-15-sect-1 | 09:28 |
| Xark | perused* | 09:29 |
| stekern | hmm, yes, but it was a while since I read that, thanks for reminding me about that document | 09:31 |
| Xark | stekern: Besides it "making sense". Here is some good indirect evidence that multiple virtual addresses can map to a single physical address (when counting "used" memory) -> http://www.eqware.net/Articles/CapturingProcessMemoryUsageUnderLinux/index.html | 09:31 |
| Xark | Also consider the case of multiple processes "mmap"'ing a shared writable page (so probably not read only). | 09:31 |
| Xark | Of course, different CPUs have to deal with cache coherence different ways (on some systems, cache will be flushed when MMU is remapped, e.g.). | 09:32 |
| stekern | mmm, I kind of suspected that it would be the case | 09:43 |
| * Xark notes he is just starting to look into openrisc (and FPGA and soft-cores in general) so is not really familiar with openrisc MMU specifics (hopefully a bit improved over MIPS). | 09:56 | |
| stekern | I haven't looked at MIPS MMU, what are the problems there? | 09:58 |
| stekern | I'm currently implementing MMUs for mor1kx (https://github.com/openrisc/mor1kx) | 09:59 |
| stekern | and as always, I know nothing when I start, and am happily learning during the journey ;) | 09:59 |
| Xark | stekern: Well, I am not sure of the specifics, but I believe it was very expensive CPU wise to manage the MMU (and I think required a slow remapping between task switches). | 10:00 |
| Xark | http://en.wikipedia.org/wiki/Memory_management_unit#MIPS ... but not too much detail. | 10:01 |
| stekern | yeah, software TLB refill | 10:03 |
| Xark | I think the overhead of that TLB refill exception is what I am thinking of (some MIPS systems I worked on had an "identity mapping" on the MMU so they never needed to deal with the >10% overhead - or something painful). | 10:03 |
| stekern | or1200 does that too | 10:03 |
| stekern | and the first incarnation of the MMUs I'm working too as well | 10:03 |
| Xark | Also depends how big TLB cache is (it was "too small" on some MIPS chips). | 10:03 |
| stekern | but I'd like to do hardware walking in the future | 10:03 |
| stekern | the openrisc architecture supports 4 ways x 128 entries | 10:08 |
| stekern | iirc, or1200 have 1 way x 64 | 10:09 |
| Xark | stekern: That is the TLB or the cache? | 10:10 |
| stekern | TLB | 10:10 |
| Xark | The (older) MIPS R4000ish system I am thinking of had (looks like) 48x1. | 10:11 |
| blueCmd | stekern: had any time to run my patches through that regression thing of yours? | 22:18 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!