From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 13:46:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FD641065679; Fri, 27 Mar 2009 13:46:09 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 10A738FC21; Fri, 27 Mar 2009 13:46:08 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 9C4A478CCB; Fri, 27 Mar 2009 13:46:07 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n2RDk7Lo004956; Fri, 27 Mar 2009 13:46:07 GMT (envelope-from phk@critter.freebsd.dk) To: Prashant Vaibhav From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 27 Mar 2009 18:25:58 +0530." <17560ccf0903270555oe7d1652p7414a221aa2d6167@mail.gmail.com> Date: Fri, 27 Mar 2009 13:46:07 +0000 Message-ID: <4955.1238161567@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 13:46:10 -0000 In message <17560ccf0903270555oe7d1652p7414a221aa2d6167@mail.gmail.com>, Prashant Vaibhav writes: >>[...] these must provide a monotonic timescale when queried interleaved >> ? Be aware that the TSC may not be, and may not stay synchronized across >> multiple cores. > >The TSC is documented to be monotonically increasing [...] Notice the absence of the word "regular" ? That it is "monotonically increasing" just means that it does not count backwards (except on the buggy cpu-revs where it does). It does not mean that it counts upwards at a stable or constant rate. >>Further more, the TSC is not constant frequency and in particular not >> "known frequency" at all times. > >The TSC is guaranteed to be constant frequency on relatively modern >processors from Intel and AMD [...] Which is why you will neeed a {CPU+MOBO+BIOS} table of known good combinations: the majority of systems out there does not guarantee and some of those that do lie. Or have bugs. Or both. >>There are a lot of nasty cases to check, > >They're not very involved in my opinion. Then you likely have not done enough :-) >>and a nasty interpolation required, > >Could you please elaborate or hint me on some terms I can google about the >interpolations that are required? Are you referring to the interpolation >needed during measuring the tsc frequency to account for the (weird) >duration of PIT? This happens during bootup only. I'm talking about the systems where SMM bios operations cause the different CPU's TSC to develop skew over time. >>which, in my tests some years back, totally negated any speedup from using >> the TSC in the first place. > >This could be an issue: I have not made extensive benchmarks. The benefit of >using TSC could still be: the availability of a higher resolution timer >which can be accessed from userspace. We have the same resolution today, if you dare to enable TSC in the kernel. In fact, we have even better resolution, because the "struct bintime" format is much more precise than both timespec and timeval. So far I doubt anybody but me have tried to measure that this makes a difference :-) >>At the very minimum, you will have to add a quirk table where known good >> {CPU+MOBO+BIOS} combinations can be entered, as we find them. > >Perhaps. >Or alternatively, a quirk table for known *bad* combinations. No, FreeBSD is shipped "working by default", not "possibly working" by default and particularly not in an area, where the signs of trouble are so subtle that most people don't recognize them at all and just blame it on "random buggy crap". >>Rubbish. Timecounters are not even closely associated with the tick or > >My understanding could be flawed here, but the reasoning was: for a tickles >kernel, we need some sort of monotonically increasing, known-rate counter as >a replacement for periodic timer interrupts. We already have that in FreeBSD for CPU time accounting. The crucial fact about a tickless kernel, is that it does not take an interrupt N times a second just to see if there is anything to do in the callout queue, but instead uses the hardware timer to aim an interrupt at the next time it needs to wake up. >>the bios may autonomously change the cpu speed > >True. This could be an issue. Your optimism is cute but misguided. On most laptops the bios WILL change the CPU speed without notice in reaction to temperature and battery power. Let me repeat: >> [1] In my mind, reworking the callout system in the kernel would >> be a much better more neded and much more worthwhile project. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.