Date: Sun, 2 Feb 1997 16:44:36 -0500 From: "David S. Miller" <davem@jenolan.rutgers.edu> To: terry@lambert.org 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: <199702022144.QAA19640@jenolan.caipgeneral> In-Reply-To: <199702022135.OAA08696@phaeton.artisoft.com> (message from Terry Lambert on Sun, 2 Feb 1997 14:35:27 -0700 (MST))
next in thread | previous in thread | raw e-mail | index | archive | help
From: Terry Lambert <terry@lambert.org> Date: Sun, 2 Feb 1997 14:35:27 -0700 (MST) 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. Oh god, the APIC, programming that thing is like pulling out ones fingernails with a crowbar. They dropped those fabs on the floor big time. Intel should have sub contracted someone who knew what they were doing for that chipset. So outside of the APIC_IO cases, all else is smoothe and passes the test cases right? I mean Jesus Christ, how do you implement a read/writer lock for crying out loud with that problem? If I understand the issue properly, this means you'd have to lock the entire bus for every _access_ to any piece of the lock structure. I'm glad my primary platform isn't the Intel, but it actually a fun chip to optimize assembly for. (Note, Sun isn't the only one who got it right. SGI, HP, DEC, and just about every other hardware manufacturer whose hardware cache coherency implementation I am intimately familiar with does it right. Intel is the only fuckup case I've run into, and I had not idea it was so bad until you pointed out the problem just now.) ---------------------------------------------//// Yow! 11.26 MB/s remote host TCP bandwidth & //// 199 usec remote TCP latency over 100Mb/s //// ethernet. Beat that! //// -----------------------------------------////__________ o David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702022144.QAA19640>