From owner-svn-src-all@FreeBSD.ORG Sat Jun 23 20:01:37 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0003106564A; Sat, 23 Jun 2012 20:01:37 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8F0658FC0C; Sat, 23 Jun 2012 20:01:36 +0000 (UTC) Received: by lbon10 with SMTP id n10so6053921lbo.13 for ; Sat, 23 Jun 2012 13:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=UxHRq11drzO9aLCPpmSfVKOsy/JsYWriSoBZ0UdeyAM=; b=bgCWX2CjSwA9KexYntx3c7INIgcmM7UjcEeYYVnfeWL9LmMu8cpmJvxIrX0qn68tUL hM3XA1MKlup8pOBrB3HL3YpoTUFr/eX9nE7BdG037wptbIgr4O1294xn6pIqnBnyw0ch szMTz7lau6O0bl3Y/CIDKmcWK+vXVL+w0EmL5PM3DAVz4tUF6rA+znpki78gcaVbUORG /46dKYnmpEkn4zcGk1zuXY8fisjZInvTGvHT1BnyxfvQIbsMk48yrWV2h42QatumK/0h UJuXq6u59E2e+Qk6llg1Z4GMFA+drlEcxYrLa7J3SfXdM3b2Rv0tECREk6ZgPSw7PDVH HdjQ== Received: by 10.112.30.136 with SMTP id s8mr3417033lbh.51.1340481695323; Sat, 23 Jun 2012 13:01:35 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id xx8sm60286269lab.10.2012.06.23.13.01.32 (version=SSLv3 cipher=OTHER); Sat, 23 Jun 2012 13:01:34 -0700 (PDT) Sender: Alexander Motin Message-ID: <4FE6209B.7050809@FreeBSD.org> Date: Sat, 23 Jun 2012 23:01:31 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120621 Thunderbird/13.0.1 MIME-Version: 1.0 To: Bruce Evans References: <201206220713.q5M7DVH0063098@svn.freebsd.org> <20120622073455.GE69382@alchemy.franken.de> <20120622074817.GA2337@deviant.kiev.zoral.com.ua> <20120623131757.GB46065@alchemy.franken.de> <20120623140556.GU2337@deviant.kiev.zoral.com.ua> <20120624005418.W2417@besplex.bde.org> In-Reply-To: <20120624005418.W2417@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano , src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org, Marius Strobl , Konstantin Belousov Subject: Re: svn commit: r237434 - in head/lib/libc: amd64/sys gen i386/sys include sys X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2012 20:01:37 -0000 On 06/23/12 18:26, Bruce Evans wrote: > On Sat, 23 Jun 2012, Konstantin Belousov wrote: >> On Sat, Jun 23, 2012 at 03:17:57PM +0200, Marius Strobl wrote: >>> So apart from introducing code to constantly synchronize the >>> TICK counters, using the timecounters on the host busses also >>> seems to be the only viable solution for userland. The latter >>> should be doable but is long-winded as besides duplicating >>> portions of the corresponding device drivers in userland, it >>> probably also means to get some additional infrastructure >>> like being able to memory map registers for devices on the >>> nexus(4) level in place ... > > There is little point in optimizations to avoid syscalls for hardware. > On x86, a syscall takes 100-400 nsec extra, so if the hardware takes > 500-2000 nsec then reduction the total time by 100-400 nsec is not > very useful. Just out of curiosity I've run my own binuptime() micro-benchmarks: - on Core i5-650: TSC 11ns HPET 433ns ACPI-fast 515ns i8254 3736ns - on dual-socket Xeon E5645: TSC 15ns HPET 580ns ACPI-fast 1118ns i8254 3911ns I think it could be useful to have that small benchmark in base kernel. >> Understand. I do plan eventually to map HPET counters page into usermode >> on x86. > > This should be left out too. > >> Also, as I noted above, some code to synchronize per-package counters >> would be useful for x86, so it might be developed with multi-arch >> usage in mind. > > It's only worth synchonizing fast timecounter hardware so that it can be > used in more cases. It probably needs to be non-bus based to be fast. > That means the TSC on x86. > > The new timeout code to support tickless kernels looks like it will give > large pessimizations unless the timecounter is fast. Instead of using > the tick counter (1 atomic increment on every clock tick) and some > getbinuptime() calls in places like select(), it uses the hardware > timecounter via binuptime() in most places (since without a tick counter > and without clock interrupts updating the timehands periodically, it takes > a hardware timecounter read to determine the time). So callout_reset() > might start taking thousands of nsec for per call, depending on how slow > the timecounter is. This fix is probably to use a fuzzy time for long > long timeouts and to discourage use of short timeouts and/or to turn them > into long or fuzzy timeouts so that they are not very useful. The new timeout code is still in active development and optimization was not the first priority yet. My idea was to use much faster getbinuptime() for periods above let's say 100ms. Legacy ticks-oriented callout_reset() functions are by default not supposed to provide sub-tick resolution and with some assumptions could use getbinuptime(). For new interfaces it depends on caller, how will it get present time. I understand that integer tick counter is as fast as nothing else can ever be. But sorry, 32bit counter doesn't fit present goals. To have more we need some artificial atomicity -- exactly what getbinuptime() implements. What I would like to see there is tc_tick removal to make tc_windup() called for every hardclock tick. Having new tick-irrelevant callout interfaces we probably won't so much need to increase HZ too high any more, while this simplification would make ticks and getbinuptime() precision equal, solving some of your valid arguments against the last. -- Alexander Motin