Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935042AbWKXUr6 (ORCPT ); Fri, 24 Nov 2006 15:47:58 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S935056AbWKXUr6 (ORCPT ); Fri, 24 Nov 2006 15:47:58 -0500 Received: from firewall.rowland.harvard.edu ([140.247.233.35]:43201 "HELO netrider.rowland.org") by vger.kernel.org with SMTP id S935042AbWKXUr6 (ORCPT ); Fri, 24 Nov 2006 15:47:58 -0500 Date: Fri, 24 Nov 2006 15:47:56 -0500 (EST) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: Oleg Nesterov cc: "Paul E. McKenney" , Jens Axboe , Subject: Re: [patch] cpufreq: mark cpufreq_tsc() as core_initcall_sync In-Reply-To: <20061124182153.GA9868@oleg> Message-ID: 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 Content-Length: 911 Lines: 22 On Fri, 24 Nov 2006, Oleg Nesterov wrote: > Ok, synchronize_xxx() passed 1 hour rcutorture test on dual P-III. > > It behaves the same as srcu but optimized for writers. The fast path > for synchronize_xxx() is mutex_lock() + atomic_read() + mutex_unlock(). > The slow path is __wait_event(), no polling. However, the reader does > atomic inc/dec on lock/unlock, and the counters are not per-cpu. > > Jens, is it ok for you? Alan, Paul, what is your opinion? Given that you aren't using per-cpu data, why not just rely on a spinlock? Then everything will be simple and easy to verify, with no need to worry about atomic instructions or memory barriers. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/