[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <OFD1FB1C34.F6D155B5-ON802571F5.002E016F-802571F5.002FE50E@uk.ibm.com>
Date: Tue, 26 Sep 2006 09:43:08 +0100
From: Richard J Moore <richardj_moore@...ibm.com>
To: Hugh Dickins <hugh@...itas.com>
Cc: linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: score-boarding [was Re: [PATCH] Linux Kernel Markers]
Hugh Dickins <hugh@...itas.com> wrote on 23/09/2006 16:34:33:
> On Thu, 21 Sep 2006, Richard J Moore wrote:
> >
> > It can for another reason - score-boarding: that's where a byte being
> > stored assumes intermediate values due to the bits not being set
> > simultaneously. Generally this doesn't cause a problem because data
across
> > processors is serialised for update by mutexes. However, when applied
to
> > code all sorts of interesting instructions can execute before the bits
> > settle down. I haven't heard of this troubling Intel, but it does occur
on
> > some current architectures.
>
> I'd not heard of this phenomenon, and it worries me. There are places
> in kernel code where we peek at some volatile variable (perhaps a long)
> without locking, and expect to see it in any one of several well-defined
> states. Are you saying that there are architectures supported by Linux,
> on which we might see an "impossible" mix of states, due to
score-boarding?
>
> Hugh
These things tend not to be discussed in specific detail in the processor
reference manuals. If there are exposures they are generally covered by
blanket statements about the need to ensure correct serialization between
processors when reading from, and writing to, the same location. As far as
I am aware Linux is protected from such affects because we do use locks, or
serializing instructions, to protect the updating of variables that are
accessed by multiple processors. My guess is that the exposure to
score-boarding, if it exists at all, tends to be limited to concurrent
bitwise operations.
Richard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists