Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S290020AbUKAX3L (ORCPT ); Mon, 1 Nov 2004 18:29:11 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267155AbUKAX3K (ORCPT ); Mon, 1 Nov 2004 18:29:10 -0500 Received: from alog0023.analogic.com ([208.224.220.38]:7552 "EHLO chaos.analogic.com") by vger.kernel.org with ESMTP id S376349AbUKAWYX (ORCPT ); Mon, 1 Nov 2004 17:24:23 -0500 Date: Mon, 1 Nov 2004 17:22:27 -0500 (EST) From: linux-os Reply-To: linux-os@analogic.com To: dean gaudet cc: Linus Torvalds , Andreas Steinmetz , Kernel Mailing List , Richard Henderson , Andi Kleen , Andrew Morton , Jan Hubicka Subject: Re: Semaphore assembly-code bug In-Reply-To: Message-ID: References: <417550FB.8020404@drdos.com> <1098218286.8675.82.camel@mentorng.gurulabs.com> <41757478.4090402@drdos.com> <20041020034524.GD10638@michonline.com> <1098245904.23628.84.camel@krustophenia.net> <1098247307.23628.91.camel@krustophenia.net> <41826A7E.6020801@domdv.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2010 Lines: 81 On Mon, 1 Nov 2004, dean gaudet wrote: > On Mon, 1 Nov 2004, linux-os wrote: > >> On Mon, 1 Nov 2004, dean gaudet wrote: >> >>> On Sun, 31 Oct 2004, linux-os wrote: >>> >>>> Timer overhead = 88 CPU clocks >>>> push 3, pop 3 = 12 CPU clocks >>>> push 3, pop 2 = 12 CPU clocks >>>> push 3, pop 1 = 12 CPU clocks >>>> push 3, pop none using ADD = 8 CPU clocks >>>> push 3, pop none using LEA = 8 CPU clocks >>>> push 3, pop into same register = 12 CPU clocks >>> >>> your microbenchmark makes assumptions about rdtsc which haven't been valid >>> since the days of the 486. rdtsc has serializing aspects and overhead that >>> you can't just eliminate by running it in a tight loop and subtracting out >>> that "overhead". >>> >> >> Wrong. > > if you were correct then i should be able to measure 1 cycle differences > in sequences such as the following: [SNIPPED...] Who said? The resolution isn't even specified. Experimental results with several different processors seem to show that the resolution is about 4 cycles. Script started on Mon 01 Nov 2004 04:48:04 PM EST # ./tester Timer overhead = 88 CPU clocks 1 nop = 4 CPU clocks 2 nops = 4 CPU clocks 3 nops = 4 CPU clocks 4 nops = 8 CPU clocks 5 nops = 8 CPU clocks 6 nops = 8 CPU clocks 7 nops = 8 CPU clocks 8 nops = 12 CPU clocks # exit Script done on Mon 01 Nov 2004 04:48:34 PM EST Assembly : nop8: nop nop7: nop nop6: nop nop5: nop nop4: nop nop3: nop nop2: nop nop1: nop ret .global nop1 .global nop2 .global nop3 .global nop4 .global nop5 .global nop6 .global nop7 .global nop8 Cheers, Dick Johnson Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by John Ashcroft. 98.36% of all statistics are fiction. - 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/