linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luke Kenneth Casson Leighton <luke.leighton@gmail.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: paulmck@linux.vnet.ibm.com, Will Newton <will.newton@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: advice sought: practicality of SMP cache coherency implemented in assembler (and a hardware detect line)
Date: Tue, 29 Mar 2011 00:38:49 +0100	[thread overview]
Message-ID: <AANLkTimXztH_4f1=7-Ez6j-7UESroqwBvVuDNW7Fmewb@mail.gmail.com> (raw)
In-Reply-To: <20110328231818.2297408f@lxorguk.ukuu.org.uk>

On Mon, Mar 28, 2011 at 11:18 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>>  ok - well, having thought about this a little bit (in a non-detailed
>> high-level way) i was sort-of hoping, as alan hinted at, to still do
>> SMP, even if it's slow, for userspace.   the primary thing to prevent
>> from happening is to have kernelspace data structures from
>> conflicting.
>>
>>  i found kerrigan, btw, spoke to the people on it: louis agreed that
>> the whole idea was mad as hell and was therefore actually very
>> interesting to attempt :)
>>
>>  as a first approximation i'm absolutely happy for existing pthreads
>> applications to be forced to run on the same core.
>
> The underlying problem across a cluster of nodes can be handled
> transparently. MOSIX solved that problem a very long time ago using DSM
> (distributed shared memory). It's not pretty, it requires a lot of tuning
> to make it fly but they did it over comparatively slow interconnects.

 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?

 it had occurred to me, btw, that it would be good to have separate
interrupts for userspace and kernelspace.  kernelspace would have a
"serious problem occurred!" interrupt handler and userspace would have
the horribly-slow-but-tolerable cache-flush assembly code.

 is that preferable over - faster than - the MOSIX DSM solution, do you think?

 l.

 p.s. alan am not ignoring what you wrote, it's just that if this goes
ahead, it has to be done _quickly_ and without requiring
re-verification of large VHDL macro blocks.  of the two companies
whose cores are under consideration, neither of them have done SMP
variants (yet) and we haven't got the time to wait around whilst they
get it done.  so these beautiful and hilarious hacks, which can be
tacked onto the outside, are what we have to live with for at least oo
18 months, get a successful saleable core out, that pays for the work
to be done proppa :)

  reply	other threads:[~2011-03-28 23:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-25 21:52 advice sought: practicality of SMP cache coherency implemented in assembler (and a hardware detect line) Luke Kenneth Casson Leighton
2011-03-25 22:41 ` Will Newton
2011-03-26 12:08   ` Alan Cox
2011-03-28 18:06     ` Paul E. McKenney
2011-03-28 18:48       ` Luke Kenneth Casson Leighton
2011-03-28 22:12         ` Paul E. McKenney
2011-03-28 22:18         ` Alan Cox
2011-03-28 23:38           ` Luke Kenneth Casson Leighton [this message]
2011-03-28 23:39             ` Luke Kenneth Casson Leighton
2011-03-28 23:53               ` Paul E. McKenney
2011-03-29  9:16             ` Alan Cox
2011-04-07 12:09               ` Luke Kenneth Casson Leighton
2011-04-08 16:24                 ` Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='AANLkTimXztH_4f1=7-Ez6j-7UESroqwBvVuDNW7Fmewb@mail.gmail.com' \
    --to=luke.leighton@gmail.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=will.newton@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).