From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030943AbWFOSPA (ORCPT ); Thu, 15 Jun 2006 14:15:00 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030945AbWFOSO7 (ORCPT ); Thu, 15 Jun 2006 14:14:59 -0400 Received: from omx2-ext.sgi.com ([192.48.171.19]:58529 "EHLO omx2.sgi.com") by vger.kernel.org with ESMTP id S1030943AbWFOSO7 (ORCPT ); Thu, 15 Jun 2006 14:14:59 -0400 Date: Thu, 15 Jun 2006 11:14:47 -0700 (PDT) From: Christoph Lameter To: Zoltan Menyhart cc: akpm@osdl.org, ak@suse.de, linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org Subject: Re: light weight counters: race free through local_t? In-Reply-To: <44918EE5.2060302@bull.net> Message-ID: References: <449033B0.1020206@bull.net> <44915110.2050100@bull.net> <44918EE5.2060302@bull.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Given what you just said it seems that an atomic op is better than first reading the cacheline and then incrementing a value in it right? Because if we first read then we acquire the cacheline in shared more. Later when we write to it we have to acquire it again in exclusive mode. The fetchadd would acquire the cacheline immediately in exclusive mode and thus save the acquisition in shared mode. > Yes, it is a one-direction barrier. > However, if there is not too many stuff in the OzQ, it has not too much > impact. It serializes prior accesses and has a simiar effect as an unlock operation. The processor cannot freely reorder instructions around the increment. That must have some sort of an impact on performance. > I still prefer the atomic operations. Noted. Andi: It seems that we can fall back on ia64 to an atomic operation without concern for performance.