prefer tsc timecounter when it's good
Andriy Gapon
avg at FreeBSD.org
Wed Apr 27 07:07:45 UTC 2011
on 26/04/2011 20:49 Jung-uk Kim said the following:
> Can you please test attached patch? You can get it from here, too:
>
> http://people.freebsd.org/~jkim/tsc_smp_test.diff
I am planning on testing the patch, but I am a little bit busy with other things
at the moment.
The idea looks good to me. The code is a little bit hard to follow :-)
I would use three separate array instead of a single array with triple size (for
clarity). The arrays would have to be placed inside a structure for passing to
smp_rendezvous.
Also, perhaps a single rendezvous per iteration would be sufficient, so that you
get four values to compare per a pair of CPUs, instead of current six. Again to
make the code simpler / more readable. That would allow to expand TSC_READ
macro as well (two copies of the function would take less lines than the macro).
BTW, not sure if you actually need 'volatile' inside tsc_read_X.
> Currently this patch samples 3,000 times to determine if any CPU has
> out-of-order TSC but it may be too much, especially for large SMP
> machines. If it takes too long, I'll lower the number. Please
> report if that's the case.
>
> Please note this patch also changes HPET, ACPI-fast and TSC qualities.
> However, TSC on SMP does not change the default quality, i.e., HPET
> or ACPI timer will be chosen by default, because we cannot be sure if
> they'll drift later. If the user is sure that they don't drift AND
> it is absolutely constant, kern.timecounter.smp_tsc tunable can be
> used to set better quality.
- You changing the relative priorities of HPET and ACPI-fast. I support this
change (some others may not), but please make it as a separate commit.
- Not sure if the quality test code is of much use if a user has to set some
tunable to actually use it over HPET or ACPI-fast. I thought that the whole
point was in automatically choosing the best timecounter. I would go the
opposite way - if automatic selection of TSC causes any trouble then provide a
way to disable it.
--
Andriy Gapon
More information about the freebsd-current
mailing list