Hello everyone,
Intel has never seen a sighting or issue related to the implementation of
unlock using movb for Pentium or Pentium Pro famlily of processors.
This is true as long as the acquiring processor always uses a locked rmw
instruction to acquire the lock. If the processors depend upon memory
ordering for acquire and release without lock, there is an errata (66 in the
Pentium Pro manual) that is ~ "Delayed Invalidation of Cache Line" where
boundary conditions may occur.
You do not need CONFIG_X86_MOVB_SPIN_UNLOCK and you can always use movb for
all Intel processors.
Thanks
Sunil
Oliver Xymoron <oxymoron@waste.org <mailto:oxymoron@waste.org>> wrote in
message <news:Pine.LNX.4.10.10004231044050.25659-100000@waste.org>...> On
Sat, 22 Apr 2000, Oliver Xymoron wrote:
>
> > On Sat, 22 Apr 2000, Jamie Lokier wrote:
> >
> > > Linus Torvalds wrote:
> > > > I have conflicting reports about the safety of "movb" from Intel.
> > > > According to some people in there, "movb" is always safe, and there
should
> > > > not be any need for any config option at all.
> > > >
> > > > However, at the same time my original contact at intel was Andy
Glew, who
> > > > probably knows more about the ia32 core than anybody else I know.
And Andy
> > > > says that yes "movb" is legal, but that some very early P6 steppings
may
> > > > be buggy. And Andy is God.
> > >
> > > That comment in <asm-i386/spinlock.h> is rather tantalising. It says
> > > don't use "movb" because it doesn't work but gives no clues why.
> > >
> > > I still have the thread where this was hashed out. And it seemed very
> > > few people ended up understanding the precise reason for not using
> > > "movb". Not me :-(
> >
> > There are very few things that could cause the movb to be a problem. For
> > instance, it can't be in the cache coherency protocol as the unlock can
> > be lazy at it likes and still be safe. My only guess is that somehow the
> > movb can get scheduled ahead of reads or writes inside the critical
> > section. If that's the case, then the whole coherency scheme is broken,
> > no? We'd need to rethink quite a number of things we've presumed safe.
> > My guess is the whole thing is apocryphal.
>
> Ok, I read the Pentium Pro errata, available at
>
> <http://developer.intel.com/design/pro/specupdt/242689.htm>
>
> and the issues relevant to MP locking appear to be 1, 39, 41, 51, 66, and
> 92. All but 1 and 92 were fixed in the PPro. Some of them are about
> processors having inconsistent MTRR settings (which should be a non-issue
> for us) while the others are about cache coherency and snooping. From my
> reading the latter allow may allow violations of write-ordering but none
> that would allow a second processor to acquire a lock before the first had
> released it. This is not surprising as the spinlock *would have to see
> someone unlock before the unlock actually happened*. That'd be spooky. So
> again, the unlock is just inherently safer than the lock side. Everyone
> feel free to double-check this, but I still see no reason we can't use the
> faster movb.
>
> Below is Manfred's lock test code if people with Pentium Pros want to
> bang on it. If it locks up, we have a problem. Set USE_MB to one to use
> the mov-based unlock. My dual PPro is a later stepping 9 and seems to work
> just fine. If you have an SMP system with steppings 1-8 (only 1, 2, 6, and
> 7 should be out there) and can confirm this works for you, that'd be
> great.
-
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/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:08 EST