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

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.