Messages in this thread | | | Date | Thu, 7 Apr 2011 13:09:29 +0100 | Subject | Re: advice sought: practicality of SMP cache coherency implemented in assembler (and a hardware detect line) | From | Luke Kenneth Casson Leighton <> |
| |
alan, paul, will, apologies for not responding sooner, i've just moved to near stranraer, in scotland. och-aye. the removal lorry has been rescued from the mud by an 18 tonne tractor and we have not run over any sheep. yet.
On Tue, Mar 29, 2011 at 10:16 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: >> hmmm, the question is, therefore: would the MOSIX DSM solution be >> preferable, which i presume assumes that memory cannot be shared at >> all, to a situation where you *could* at least get cache coherency in >> userspace, if you're happy to tolerate a software interrupt handler >> flushing the cache line manually? > > In theory DSM goes further than this. One way to think about DSM is cache > coherency in software with a page size granularity. So you could imagine > a hypothetical example where the physical MMU of each node and a memory > manager layer comnunicating between them implemented a virtualised > machine on top which was cache coherent.
> [...details of M.E.S.I ... ]
well... the thing is that there already exists an MMU per core. standard page-faults occur, etc. in this instance (i think!), just as would occur in any much more standard SIMD architecture (with normal hardware-based 1st level cache coherency)
hm - does this statement sound reasonable: this is sort-of a second-tier of MMU principles, with a page size granularity of 8 bytes (!) with oo 4096 or 8192 such "pages" (32 or 64k or whatever of 1st level cache). thus, the principles you're describing [M.E.S.I] could be applied, even at that rather small level of granularity.
or... wait... "invalid" is taken care of at a hardware level, isn't it? [this is 1st level cache]
much appreciated the thoughts and discussion so far.
l. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |