Date: Wed, 02 Jan 2002 12:43:26 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Michal Mertl <mime@traveller.cz>, Bruce Evans <bde@zeta.org.au>, Mike Smith <msmith@FreeBSD.ORG>, Bernd Walter <ticso@cicely8.cicely.de>, arch@FreeBSD.ORG Subject: Re: When to use atomic_ functions? (was: 64 bit counters) Message-ID: <3C3370EE.7621E667@mindspring.com> References: <Pine.BSF.4.41.0201021003580.18429-100000@prg.traveller.cz> <200201022033.g02KXNV59224@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote: > :I don't know how much time will be wasted - my measurements on pII show > :the atomic_ operations aren't that expensive. > > An atomic operation is not that expensive as long as only one cpu > is touching the cache line. Try running two user processes writing > the same cache line on an SMP system and you will see performance > drop by a factor of 5-10. Matt is correct (if in doubt, Matt is usually correct 8-)). The only way to address this decently is to reduce contention domains in the design. Initially, this won't happen; I expect that it will have to come subsystem by subsystem at a later date, as people hit performance bottlenecks. > Now, of course, we could lock each interface to a particular cpu. There > are advantages to doing that. This is something that should at least be permitted by any final design, if not actively encouraged, or implemented up front. This is what NT did to beat Linux on the MindCraft and other benchmarks. There are also some serious penalties associated with the way FreeBSD does it now (interrupts are wired to the sole CPU in the kernel) and the way Intel wants it done (virtual wire mode means every CPU gets an IPI), and both of these limit scalability significantly. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C3370EE.7621E667>