Date: Fri, 27 Mar 2009 19:48:45 +0530 From: Prashant Vaibhav <prashant.vaibhav@gmail.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: freebsd-current@freebsd.org Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) Message-ID: <17560ccf0903270718k3688d520y4e1aca30b6aeacdb@mail.gmail.com> In-Reply-To: <4955.1238161567@critter.freebsd.dk> References: <17560ccf0903270555oe7d1652p7414a221aa2d6167@mail.gmail.com> <4955.1238161567@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
>
> >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 <phk@phk.freebsd.dk>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.
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17560ccf0903270718k3688d520y4e1aca30b6aeacdb>