Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934804AbXHZB1s (ORCPT ); Sat, 25 Aug 2007 21:27:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756916AbXHZB1n (ORCPT ); Sat, 25 Aug 2007 21:27:43 -0400 Received: from ms-smtp-01.nyroc.rr.com ([24.24.2.55]:62182 "EHLO ms-smtp-01.nyroc.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752246AbXHZB1m (ORCPT ); Sat, 25 Aug 2007 21:27:42 -0400 Date: Sat, 25 Aug 2007 21:26:42 -0400 (EDT) From: Steven Rostedt X-X-Sender: rostedt@gandalf.stny.rr.com To: "Frank Ch. Eigler" cc: Ingo Molnar , LKML , RT , Thomas Gleixner , john stultz Subject: Re: [PATCH RT 3/3 - take two ] fix get_monotonic_cycles for latency tracer In-Reply-To: Message-ID: References: <1187978236.2941.19.camel@localhost.localdomain> <1187982149.4574.1.camel@localhost.localdomain> 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: 1464 Lines: 40 -- On Sat, 25 Aug 2007, Frank Ch. Eigler wrote: > > Steven Rostedt writes: > > > [...] > > + * [...] We don't need to grab > > + * any locks, we just keep trying until get all the > > + * calculations together in one state. > > + * > > + * In fact, we __cant__ grab any locks. This > > + * function is called from the latency_tracer which can > > + * be called anywhere. To grab any locks (including > > + * seq_locks) we risk putting ourselves into a deadlock. > > Perhaps you could add a comment about why the loop, which appears > potentially infinite as written, avoids livelock. (It looks rather > like a seqlock read loop.) > I guess I need to rewrite that comment. It shouldn't appear infinitely looping, since it is basically: do { x=A; func() } while (x != A); which to me seems that while is most likely to fail unless something touches A. But yes, it _is_ basically a seq lock, but its on what we are working with. And we don't even need any memory barriers that a seq lock might do, since it is very obvious to gcc that the function call can modify the variables that we are testing. But do you still think that looks inifinte? If so, I'll reword it. -- Steve - 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/