From owner-svn-src-projects@FreeBSD.ORG Sat Jun 2 14:56:14 2012 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A8D941065670; Sat, 2 Jun 2012 14:56:14 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id DCC7A8FC15; Sat, 2 Jun 2012 14:56:13 +0000 (UTC) Received: by wibhn6 with SMTP id hn6so1237295wib.13 for ; Sat, 02 Jun 2012 07:56:12 -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=a1UF2eED5sbkDaBaR6mE+QTat2oPbue7+c4R99GjqiY=; b=twp3v3T3PTNMRC48s7l1+oMvs+COoyGP3zP1jrMfsX329Knd7SdPrusZxpjP68MT4D qqO6/v1aC1oIkhWgrO90OGW2NZsrWhoHCqNLC1W9pl4j28LU/Bl3w7XdiAB2WmsX8ZhN l88RGtMzBeSLEKxvgmGYdo66bOFa6g/EJaw51eXBPIwgd4kwCn2SSQhrd30fnZ3rGqIL 2tpZwy8LdGXR8xb04HuR3Q/F1dwsaYZrpS0W5iQjTMGea/hKrEBZ3qZLOyYFYbSmd30I XkDYyY2HTbUSOGdxt8lMkU4sMPDIqY1rnhpLq1OApsFTaB4K+dxDsQPkdeHwQW3duoFJ 6aEg== Received: by 10.216.216.226 with SMTP id g76mr5340197wep.221.1338648972833; Sat, 02 Jun 2012 07:56:12 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id d10sm8507268wiy.3.2012.06.02.07.56.10 (version=SSLv3 cipher=OTHER); Sat, 02 Jun 2012 07:56:11 -0700 (PDT) Sender: Alexander Motin Message-ID: <4FCA2988.8090106@FreeBSD.org> Date: Sat, 02 Jun 2012 17:56:08 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120328 Thunderbird/10.0.3 MIME-Version: 1.0 To: Bruce Evans References: <201206021304.q52D4p2X090537@svn.freebsd.org> <20120602233307.S1957@besplex.bde.org> In-Reply-To: <20120602233307.S1957@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano , svn-src-projects@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r236449 - projects/calloutng/sys/kern X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 14:56:14 -0000 On 06/02/12 17:16, Bruce Evans wrote: > On Sat, 2 Jun 2012, Davide Italiano wrote: > >> Log: >> Replace binuptime() with getbinuptime() because it's suitable for the >> purpose and it's cheaper. Update the relative comment on precision error >> during callwheel scan as well. > > This makes even less sense than converting to bintimes at all. > getbinuptime() can give an even lower precision than the current timer > ticks, since it is only updated every tc_tick/hz seconds while ticks > are updated every 1/hz seconds. Also, you have to keep timeouts firing > for getbintime() to work. OTOH, bintime() is unusable in timeout code, > since it may be too inefficient, depending on the timecounter hardware. > cpu_ticks() might be usable. It doesn't use bintimes and isn't very > accurate, but these are other bugs which become features for use here. You are right. It was misunderstanding and we have already revealed it. >> Modified: projects/calloutng/sys/kern/kern_timeout.c >> ============================================================================== >> >> --- projects/calloutng/sys/kern/kern_timeout.c Sat Jun 2 12:26:14 2012 >> (r236448) >> +++ projects/calloutng/sys/kern/kern_timeout.c Sat Jun 2 13:04:50 2012 >> (r236449) >> @@ -373,9 +373,9 @@ callout_tick(void) >> need_softclock = 0; >> cc = CC_SELF(); >> mtx_lock_spin_flags(&cc->cc_lock, MTX_QUIET); >> - binuptime(&now); >> + getbinuptime(&now); >> /* >> - * Get binuptime() may be inaccurate and return time up to 1/HZ in >> the past. >> + * getbinuptime() may be inaccurate and return time up to 1/HZ in the >> past. >> * In order to avoid the possible loss of one or more events look back >> 1/HZ >> * in the past from the time we last checked. >> */ > > Up to tc_tick/hz, not up to 1/HZ. tc_tick is the read-only sysctl > variable kern.timecounter.tick that is set to make tc_tick/hz as close > to 1 msec as possible. If someone asks for busy-waiting by setting > HZ to much larger than 1000 and uses this to generate lots of timeouts, > they probably get this now, but get*time() cannot be used even to > distingish times differing by the timeout granularity. It is hard to > see how it could ever work for the above use (timout scheduling with > a granularity of ~1/hz when you can only see differences of ~tc_tick/hz, > with tc_tick quite often 4-10, or 100-1000 to use or test corner > cases??). With a tickless kernel, timeouts wouldn't have a fixed > granularity, but you need accurate measurements of times even more. > One slow way to get them is to call binuptime() again in the above. > Another, even worse way to update timecounters after every timeout > expires (the update has a much higher overhead than binuptime(), so > this will be very slow iff timeouts that expire are actually used). I agree with the first part, but could you tell more about tc_windup() complexity? There are a lot of time passed since that code was written, CPUs got faster and I have feeling that cost of that math could reduce and may be not so significant now. May be at least tc_windup() could be refactored to separate time updating (making it's cost closet to single binuptime() call) and all other fancy (complicated) things? New eventtimers(4) subsystem uses binuptime() a lot. As soon as we already reading relatively slow timecounter hardware, it would be nice to get some benefit from it. -- Alexander Motin