From owner-freebsd-arch@FreeBSD.ORG Thu Jun 7 08:26:18 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 464A2106564A; Thu, 7 Jun 2012 08:26:18 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id EB3AE8FC08; Thu, 7 Jun 2012 08:26:17 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id E482C682D; Thu, 7 Jun 2012 08:26:10 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 8DD0A9A65; Thu, 7 Jun 2012 10:26:10 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Bruce Evans References: <201206051008.29568.jhb@freebsd.org> <86haupvk4a.fsf@ds4.des.no> <201206051222.12627.jhb@freebsd.org> <20120605171446.GA28387@onelab2.iet.unipi.it> <20120606040931.F1050@besplex.bde.org> <864nqovoek.fsf@ds4.des.no> <20120607064951.C1106@besplex.bde.org> Date: Thu, 07 Jun 2012 10:26:10 +0200 In-Reply-To: <20120607064951.C1106@besplex.bde.org> (Bruce Evans's message of "Thu, 7 Jun 2012 07:14:06 +1000 (EST)") Message-ID: <86sje7sf31.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 07 Jun 2012 11:13:20 +0000 Cc: Gianni , John Baldwin , Alan Cox , Alexander Kabaev , Attilio Rao , Konstantin Belousov , freebsd-arch@FreeBSD.org, Konstantin Belousov Subject: Re: Fast vs slow syscalls (Re: Fwd: [RFC] Kernel shared variables) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 08:26:18 -0000 Bruce Evans writes: > Now 2.44 nsec/call makes sense, but you really should add some volatiles > here to ensure that getpid() is not optimized away. As you can see from the disassembly I provided, it isn't. > SO it loops OK, but we can't see what getpid() does. It must not be > doing much. Umm, yes, that's the whole point of this conversation. Linux's getpid() is not a syscall, but a library function that returns a constant from a page shared by the kernel. > 5.4104 nsec/call for gettimeofday() is impossible if there is any > rdtsc() hardware call or much layering. It's gettimeofday(0, 0), actually, so it doesn't need to read the clock. If I pass a struct timeval as the first argument - so it *does* need to read the clock - it's a little bit slower but still faster than an actual system call. Here's another run that demonstrates this - a little bit slower than previous runs because I have other processes running: getpid(): 10,000,000 iterations in 30,377 us gettimeofday(0, 0): 10,000,000 iterations in 55,571 us gettimeofday(&tv, 0): 10,000,000 iterations in 302,634 us kill(pid, 0): 10,000,000 iterations in 1,291,793 us I can't test a static build since RHEL6 does not provide a static libc. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no