From: "Kevin D. Kissell" <kevink@mips.com>
To: "Jun Sun" <jsun@mvista.com>
Cc: <carlson@sibyte.com>, "Matthew Dharm" <mdharm@momenco.com>,
<linux-mips@oss.sgi.com>
Subject: Re: Multiple processor support?
Date: Thu, 29 Mar 2001 11:16:41 +0200 [thread overview]
Message-ID: <000901c0b830$fed84060$0deca8c0@Ulysses> (raw)
In-Reply-To: 3ABF9683.1D08617B@mvista.com
> > (Software cache coherency) It is possible,
> > but tricky, and at times unavoidably inefficient to build a
> > software-coherent SMP system. I have not heard of anyone
> > doing so with MIPS/Linux.
> >
>
> How would it be possible? Any reference to the previous implementations?
Lots of work on software coherent schemes was done in the
mid-late 1980s. Check out the ASPLOS, and ISCA proceedings
from the period for references. In essence, such schemes involve
the identification of critical regions at risk, the use of barriers around
such regions, and an explicit cache flush/purge protocol. You can think
of the more common MP "TLB shootdown" protocols as being a variant
of a software cache coherence scheme.
> I imagine you would need at least some kind of atomic operation (like
ll/sc)
> working reliably (which itself may require cache coherency).
MIPS ll/sc, as defined and implemented, does require hardware
coherency support for correct multiprocessor operation. But one
can, in principle, construct a software-coherent SMP system even
in the absence of such a primitive - many of the implementations
of software coherent SMPs used software coherence precisely
because they were based on simple switch/crossbar interconnects
where snooping was not possible.
> Also, any such
> scheme should not require massive change in the programming.
Whether progams need to change depends on the coherency
and consistency models assumed by the program. Certainly
a naive multithreaded program that assumes an SGI-like model
could not be dropped onto a software-coherent MP system without
recompilation with specialized compilers at a minimum, and
more likely not without recoding. On the other hand, if one's objective
is to run multiple, independent programs on different CPUs in
an SMP system, it should only be the OS that should need to
change to deal with the coherence issues for shared user pages
and shared kernel data structures, and to ensure that any
multithreaded application that is not explicitly set up to handle
software cache coherency has its threads bound to the same
CPU and caches (defeats some of the point of having a
multithreaded program, I know, but...).
Regards,
Kevin K.
WARNING: multiple messages have this Message-ID (diff)
From: "Kevin D. Kissell" <kevink@mips.com>
To: Jun Sun <jsun@mvista.com>
Cc: carlson@sibyte.com, Matthew Dharm <mdharm@momenco.com>,
linux-mips@oss.sgi.com
Subject: Re: Multiple processor support?
Date: Thu, 29 Mar 2001 11:16:41 +0200 [thread overview]
Message-ID: <000901c0b830$fed84060$0deca8c0@Ulysses> (raw)
Message-ID: <20010329091641.6NGCl8NPI1DkrC8m2NPmFyGjYR4Sn6uEY3OCAOup1YY@z> (raw)
In-Reply-To: 3ABF9683.1D08617B@mvista.com
> > (Software cache coherency) It is possible,
> > but tricky, and at times unavoidably inefficient to build a
> > software-coherent SMP system. I have not heard of anyone
> > doing so with MIPS/Linux.
> >
>
> How would it be possible? Any reference to the previous implementations?
Lots of work on software coherent schemes was done in the
mid-late 1980s. Check out the ASPLOS, and ISCA proceedings
from the period for references. In essence, such schemes involve
the identification of critical regions at risk, the use of barriers around
such regions, and an explicit cache flush/purge protocol. You can think
of the more common MP "TLB shootdown" protocols as being a variant
of a software cache coherence scheme.
> I imagine you would need at least some kind of atomic operation (like
ll/sc)
> working reliably (which itself may require cache coherency).
MIPS ll/sc, as defined and implemented, does require hardware
coherency support for correct multiprocessor operation. But one
can, in principle, construct a software-coherent SMP system even
in the absence of such a primitive - many of the implementations
of software coherent SMPs used software coherence precisely
because they were based on simple switch/crossbar interconnects
where snooping was not possible.
> Also, any such
> scheme should not require massive change in the programming.
Whether progams need to change depends on the coherency
and consistency models assumed by the program. Certainly
a naive multithreaded program that assumes an SGI-like model
could not be dropped onto a software-coherent MP system without
recompilation with specialized compilers at a minimum, and
more likely not without recoding. On the other hand, if one's objective
is to run multiple, independent programs on different CPUs in
an SMP system, it should only be the OS that should need to
change to deal with the coherence issues for shared user pages
and shared kernel data structures, and to ensure that any
multithreaded application that is not explicitly set up to handle
software cache coherency has its threads bound to the same
CPU and caches (defeats some of the point of having a
multithreaded program, I know, but...).
Regards,
Kevin K.
next prev parent reply other threads:[~2001-03-29 9:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-23 22:53 Multiple processor support? Matthew Dharm
2001-03-23 22:58 ` Justin Carlson
2001-03-24 0:01 ` Matthew Dharm
2001-03-24 0:01 ` Matthew Dharm
2001-03-24 0:08 ` Justin Carlson
2001-03-24 0:08 ` Justin Carlson
2001-03-24 0:29 ` Keith M Wesolowski
2001-03-24 0:40 ` Kevin D. Kissell
2001-03-24 0:40 ` Kevin D. Kissell
2001-03-24 1:23 ` Ralf Baechle
2001-03-24 1:23 ` Ralf Baechle
2001-03-26 19:20 ` Jun Sun
2001-03-29 9:16 ` Kevin D. Kissell [this message]
2001-03-29 9:16 ` Kevin D. Kissell
2001-03-24 0:13 ` Joe George
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='000901c0b830$fed84060$0deca8c0@Ulysses' \
--to=kevink@mips.com \
--cc=carlson@sibyte.com \
--cc=jsun@mvista.com \
--cc=linux-mips@oss.sgi.com \
--cc=mdharm@momenco.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