Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 2 Feb 1997 14:35:27 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        davem@jenolan.rutgers.edu (David S. Miller)
Cc:        terry@lambert.org, michaelh@cet.co.jp, netdev@roxanne.nuclecu.unam.mx, roque@di.fc.ul.pt, freebsd-smp@freebsd.org, smpdev@roxanne.nuclecu.unam.mx
Subject:   Re: SMP
Message-ID:  <199702022135.OAA08696@phaeton.artisoft.com>
In-Reply-To: <199702022050.PAA19542@jenolan.caipgeneral> from "David S. Miller" at Feb 2, 97 03:50:45 pm

next in thread | previous in thread | raw e-mail | index | archive | help
>    Are you claiming that CPU2 would see the write of CPU1's cache line
>    in all cases, and invalidate it's own cache line?  Isn't there a
>    potential race?  I know it's unlikely, but it exists, right?
> 
> This is the classic "Writeback Cancellation Requirement", and all
> cache coherency hardware implementations do have to deal with it
> somehow.
> 
> Check out section 7.10.3 of the UltraSparc Programmers Manual, in the
> "UltraSPARC-I External Interfaces" chapter to see how one
> implementation happens to deal the race very nicely.  The P_Reply and
> S_Reply signal synchronization rules are extremely clever here.

Well, Sun generally does things right.  I was more concerned with
a number of Intel motherboards where we are seeing APIC_IO problems.
They seem to fail this case.

I agree that the fix for this case should be hidden in the HAL,
*but* doing that would mean a severe performance hit on Intel
hardware (potentially), unless the rest of the architecture
were arranged so as to make it "inherently not a problem".

I don't know what lists you follow, but just in the past two days,
the has been a person on the FreeBSD SMP list running a motherboard
with "improved cache handling" that seems to be barfing on something
like this when APIC_IO is used... 8-(.


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702022135.OAA08696>