Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262884AbTKENiR (ORCPT ); Wed, 5 Nov 2003 08:38:17 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262887AbTKENiR (ORCPT ); Wed, 5 Nov 2003 08:38:17 -0500 Received: from intra.cyclades.com ([64.186.161.6]:8927 "EHLO intra.cyclades.com") by vger.kernel.org with ESMTP id S262884AbTKENiQ (ORCPT ); Wed, 5 Nov 2003 08:38:16 -0500 Date: Wed, 5 Nov 2003 11:35:24 -0200 (BRST) From: Marcelo Tosatti X-X-Sender: marcelo@logos.cnet To: Linus Torvalds Cc: john stultz , Joel Becker , lkml , Marcelo Tosatti Subject: Re: get_cycles() on i386 In-Reply-To: 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: 1424 Lines: 47 On Tue, 4 Nov 2003, Linus Torvalds wrote: > > On 4 Nov 2003, john stultz wrote: > > > > CONFIG_X86_TSC be the devil. Personally, I'd much prefer dropping the > > compile time option and using dynamic detection. Something like (not > > recently tested and i believe against 2.5.something, but you get the > > idea): > > Some of the users are really timing-critical (eg scheduler). > > How about just using the "alternative()" infrastructure that we already > have in 2.6.x for this? See for details. > > We don't have an "alternative_output()" available yet, but using that it > would look something like: > > static inline unsigned long long get_cycle(void) > { > unsigned long long tsc; > > alternative_output( > "xorl %%eax,%%eax ; xorl %%edx,%%edx", > "rdtsc", > X86_FEATURE_TSC, > "=A" (tsc)); > return tsc; > } > > which should allow for "perfect" code (well, gcc tends to mess up 64-bit > stuff, but you get the idea). > > We use the "alternative_input()" thing for prefetch() handling (see > ). I'm not confident this is something for 2.4. The "if (cpu_has_tsc)" fix from John sounds fine. - 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/