lkml.org 
[lkml]   [2000]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
FromOliver Xymoron <>
SubjectRe: SMP Theory (was: Re: Interesting analysis of linux kernel threading by IBM)
DateThu, 3 Feb 2000 20:58:35 -0600
On Thu, 3 Feb 2000 dg50@daimlerchrysler.com wrote:

> I've been reading the SMP thread and this is a truly educational and
> fascinating discussion. How SMP works, and how much of a benefit it
> provides has always been a bit of a mystery to me - and I think the light
> is slowly coming on.
>
> But I have a couple of (perhaps dumb) questions.
>
> OK, if you have an n-way SMP box, then you have n processors with n (local)
> caches sharing a single block of main system memory. If you then run a
> threaded program (like a renderer) with a thread per processor, you wind up
> with n threads all looking at a single block of shared memory - right?
>
> OK, if a thread accesses (I assume writes, reading isn't destructive, is
> it?) a memory location that another processor is "interested" in, then
> you've invalidated that processor's local cache - so it has to be flushed
> and refreshed.

You've only invalidated a cache line, which is still bad, but not fatal.
Applications like rendering don't often need shared write access to
anything because they can be set up to be working on different strips of
an image. There are many problems that can be made to look like lots of
separate smaller problems if looked at from the right angle, and many
graphics tasks fall into that category. The ones that aren't tend to be
things like inverting large matrices and aren't very friendly to caches,
let alone SMP.

--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:56    [from the cache]
©2003-2010