From: Will Newton <will.newton@gmail.com>
To: Luke Kenneth Casson Leighton <luke.leighton@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: advice sought: practicality of SMP cache coherency implemented in assembler (and a hardware detect line)
Date: Fri, 25 Mar 2011 22:41:40 +0000 [thread overview]
Message-ID: <AANLkTi=W0mW2o2muNgMnb1OQ6WaBeOmu1VBHr8Zf63r9@mail.gmail.com> (raw)
In-Reply-To: <AANLkTi=de3yDfXxCDp082+e3T+g_1wRWKWjqS0n1vy0+@mail.gmail.com>
On Fri, Mar 25, 2011 at 9:52 PM, Luke Kenneth Casson Leighton
<luke.leighton@gmail.com> wrote:
> so, bearing in mind that sensible answers will likely result in offers
> of a consulting contract to actually *implement* the software /
> assembly code for the linux kernel modifications required (yes, linux
> is already available for this RISC processor type - but only in
> single-core), i would greatly appreciate some help in getting answers
> to these questions:
>
> * is this even a good idea? does it "fly"?
Probably not. Is it a virtual or physical indexed cache? Do you have a
precise workload in mind? If you have a very precise workload and you
don't expect to get many write conflicts then it could be made to
work.
> * if it does work, at what point do the number of cores involved just
> make it... completely impractical? over 2? over 4? 8? 16?
You would have to simulate it with your workload to know the answer to
that, but if you're pushing to higher number of cores I think it would
pay to do this properly.
> occurred back in 2005 or so - this multi-core processor is going to be
> based around an existing proven 20-year-old well-established RISC core
> that has been running linux for over a decade, it just has never been
> put into an SMP arrangement before and we're on rather short
> timescales to get it done.
There are a number of mature cores out there that can do this already
and can be bought off the shelf, I wouldn't underestimate the
difficulty of getting your cache coherency protocol right particularly
on a limited time/resource budget.
next prev parent reply other threads:[~2011-03-25 22:41 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 [this message]
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
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='AANLkTi=W0mW2o2muNgMnb1OQ6WaBeOmu1VBHr8Zf63r9@mail.gmail.com' \
--to=will.newton@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luke.leighton@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).