From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Gabriel Paubert <paubert@iram.es>
Cc: Paul Mackerras <paulus@samba.org>,
Dan Malek <dan@embeddededge.com>, Amit Shah <amitshah@gmx.net>,
linuxppc-dev list <linuxppc-dev@lists.linuxppc.org>
Subject: Re: IBM 750GX SMP on Marvell Discovery II or III?
Date: Wed, 12 May 2004 20:26:19 +1000 [thread overview]
Message-ID: <1084357578.1933.28.camel@gaston> (raw)
In-Reply-To: <20040512080024.GA26628@iram.es>
>
> Are you sure? Since the cache lines are in the other processor memory,
> they will be flushed to RAM when they are fetched by the processor,
> provided that you can force the coherence bit on instruction fetches
> (this is possible IIRC).
Coherency of the data cache lines is one thing... getting the icbi
broadcast is another. Normal coherency will not help if you don't get
the icache of the other CPU to snoop your icbi and invalidate the trash
it has in its icache.
> As I said, I believe the real problem is multithreaded applications.
Which isn't a simple problem...
> >
> > > My experience has been that MPC750s work in a SMP environment
> > > on a 60x bus. Maybe I was just lucky? The way I read the manual,
> > > they should work with a proper memory controller.
> >
> > I think that the sorts of problems I am talking about wouldn't show up
> > very often. Generally I think that these problems would just cause
> > the system to be a bit flaky rather than stop it from working at all.
>
> I agree.
>
> > If you didn't have L2 caches that would make the problems show up less
> > frequently, too.
>
> I'm not so sure. Instruction fetches look into L2 caches. The main issue
> are:
> 1) are the instruction fetches marked coherent?
> 2) do you run multithreaded applications?
>
> If you answer yes and no, then I don't see any showstopper.
>
> Regards,
> Gabriel
>
>
> >
> > Regards,
> > Paul.
> >
>
--
Benjamin Herrenschmidt <benh@kernel.crashing.org>
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2004-05-12 10:26 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-10 7:28 IBM 750GX SMP on Marvell Discovery II or III? Amit Shah
2004-05-10 23:36 ` Paul Mackerras
2004-05-11 2:09 ` Dan Malek
2004-05-11 3:03 ` Paul Mackerras
2004-05-11 15:46 ` Dan Malek
2004-05-11 17:23 ` Huailin Chen
2004-05-11 17:31 ` Amit Shah
2004-05-11 20:51 ` Huailin Chen
2004-05-12 0:17 ` Paul Mackerras
2004-05-12 0:12 ` Paul Mackerras
2004-05-12 7:57 ` Giuliano Pochini
2004-05-12 8:00 ` Gabriel Paubert
2004-05-12 10:26 ` Benjamin Herrenschmidt [this message]
2004-05-12 11:53 ` Gabriel Paubert
2004-05-12 11:46 ` Paul Mackerras
2004-05-12 13:45 ` Gabriel Paubert
2004-05-12 14:21 ` Geert Uytterhoeven
2004-05-12 14:30 ` Amit Shah
2004-05-13 4:30 ` Bryan Rittmeyer
2004-05-14 8:02 ` Geert Uytterhoeven
2004-05-14 9:11 ` Gabriel Paubert
2004-05-11 3:08 ` Huailin Chen
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=1084357578.1933.28.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=amitshah@gmx.net \
--cc=dan@embeddededge.com \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=paubert@iram.es \
--cc=paulus@samba.org \
/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).