Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

>
> >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_at_phk.freebsd.dk>wrote:

> In message <17560ccf0903270555oe7d1652p7414a221aa2d6167_at_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_at_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.
>