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>