From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 14:18:46 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 80D3C106566B for ; Fri, 27 Mar 2009 14:18:46 +0000 (UTC) (envelope-from prashant.vaibhav@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by mx1.freebsd.org (Postfix) with ESMTP id 50C298FC13 for ; Fri, 27 Mar 2009 14:18:46 +0000 (UTC) (envelope-from prashant.vaibhav@gmail.com) Received: by rv-out-0506.google.com with SMTP id l9so1562203rvb.43 for ; Fri, 27 Mar 2009 07:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=zWHPPPiLafxNkJQmeYulLRcwtCz3bGoISbIYdKowdMc=; b=JOnyERQKkZ7Z9tZ1iNBzAUbSm21ajd8ovE5tdnHS4jv4oYOt1EQGDYwgziSolu1Zgq RGRRrofroCtv7mX8fvmi1libqUUkdfGqyKLtQA1BCZzlhyHd3tyl3EuJhM/9cHBjcmNq M6rWq2xOIl9oFK/nZw1PykEfcSG9wJv/+OJow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=X2x426vLOso2ybXouPE9yTHez642sTATIZN65nZJnFi368wLCDWuiTpM16/3189iLF ZQnBsfAQTcYDTU4zqMqbbFE93HccqRuE2bjLWLz2lW7weR2jDlV3mfkkAw7XzipBMIAc 57EV125S72H45mITo7cMk3ts8U7VzXRFBb+I4= MIME-Version: 1.0 Received: by 10.142.14.18 with SMTP id 18mr911801wfn.304.1238163525979; Fri, 27 Mar 2009 07:18:45 -0700 (PDT) In-Reply-To: <4955.1238161567@critter.freebsd.dk> References: <17560ccf0903270555oe7d1652p7414a221aa2d6167@mail.gmail.com> <4955.1238161567@critter.freebsd.dk> Date: Fri, 27 Mar 2009 19:48:45 +0530 Message-ID: <17560ccf0903270718k3688d520y4e1aca30b6aeacdb@mail.gmail.com> From: Prashant Vaibhav To: Poul-Henning Kamp Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: 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 14:18:47 -0000 > > >It does not mean that it counts upwards at a stable or constant rate. Right, I see now. >They're not very involved in my opinion. >>Then you likely have not done enough :-) Likely. Most of my ideas are based on empirical evidence so when it worked well during (non rigorous) testing I assumed it's all good. >I'm talking about the systems where SMM bios operations cause the > different CPU's TSC to develop skew over time. Ah, SMM. Out of curiosity though: doesn't that affect regular timer interrupts too (ie. they cannot be delivered if SMM is active)? >We have the same resolution today, if you dare to enable TSC in the kernel. I've noticed, and that is probably why it's limited to uniprocessor systems. >No, FreeBSD is shipped "working by default" Fundamentally different from the xnu stuff! Our goal was 'probably working' on as many non-Apple systems as possible ;-) >The crucial fact about a tickless kernel, is that it [...] uses the > hardware timer to aim an interrupt at the next time it needs to wake up. Thanks. After writing the last email I read about tickless kernels and how Linux handles it and it's clear now. My incorrect idea could probably be termed: 'interruptless kernel' :P >Your optimism is cute but misguided. Of course, I'm a student with limited kernel hacking experience. Hence this email discussion before submitting a proposal. >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. Looking into it now. Let's see if I can understand/plan this well enough to draft a good proposal within the next couple of days. Thanks again for the suggestions! Best, Prashant Vaibhav On Fri, Mar 27, 2009 at 7:16 PM, Poul-Henning Kamp wrote: > 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. >