Date: Sun, 20 Jan 2002 17:24:08 -0500 From: "Louis A. Mamakos" <louie@TransSys.COM> To: arch@FreeBSD.ORG Subject: Re: 64 bit counters again Message-ID: <200201202224.g0KMO8E56230@whizzo.transsys.com> In-Reply-To: Your message of "Mon, 21 Jan 2002 08:28:27 %2B1100." <20020121082826.Z72285@gsmx07.alcatel.com.au> References: <mit.lcs.mail.freebsd-arch/3C48A0E7.F97BC01@mindspring.com> <200201190350.g0J3oNN08944@khavrinen.lcs.mit.edu> <3C48FCEF.9190CA08@mindspring.com> <20020121082826.Z72285@gsmx07.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
[trimming the cc: list] > In a UP environment you don't need locks for either 32 or 64-bit > operations. For an SMP environment, you need locks on both. As an innocent bystander so far, let me try to state some thoughts and let me know if I'm missing something: On an SMP system, some sort of locking is required to reliably update a 32 bit or 64 bit counter. - This can be an explicit high-level locking protocol; that is, obtaining some sort of lock object, updating the data in question, and then releasing the lock object. - This can be a low-level architectural feature, such as the IA32 LOCK prefix on an instruction to convert it into an atomic R-M-W operation. Either of these mechanisms require a distributed cache-invalidating operation to achieve the multiple CPU synchronization required. And I think that there's a general sense that it's this synchronization process which is "expensive" compared to the number of instructions executed to update the counters. If a simple spin-lock was used, then you could update an arbitrarily sized counter for essentially the same cost. If you were clever enough in writing your device drivers, you could arrange to update more than one counter (e.g., packets received, octets received) using the same lock, with the additional counters for free. This needs to be weighed against the per-CPU counters and the complexity associated with them. My gut feeling is that the level of contention is low enough that spin locks should be more than adequate to protect updating a couple of counters. This assumes that spin locks have not become expensive or bloated to invalidate their usefulness, I suppose. The larger thought is that there's this unstated assumption which probably needs to be state: We have and maintain accurate statistics on various operations that the FreeBSD kernel performs. For network elements, it's assumed that there are the typical network-interface stats which we also provide. We can agonize over the cost of having to implement all these statistics, but I'd claim that the kernel is defective if it doesn't do so. louie 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?200201202224.g0KMO8E56230>