linux-kernel - Re: advice sought: practicality of SMP cache coherency implemented in assembler (and a hardware detect line)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BANLkTinrEKyYhi3ZuQz4KeA+2m6pvU4ddg@mail.gmail.com>
Date:	Thu, 7 Apr 2011 13:09:29 +0100
From:	Luke Kenneth Casson Leighton <luke.leighton@...il.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	paulmck@...ux.vnet.ibm.com, Will Newton <will.newton@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: advice sought: practicality of SMP cache coherency implemented in
 assembler (and a hardware detect line)

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@...rguk.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/