svn commit: r184108 - head/sys/i386/i386

[Attilio Rao]

2008/10/23 Dag-Erling Smørgrav <des at des.no>:
> "Attilio Rao" <attilio at freebsd.org> writes:
>> I think it is silly we have different quirks flag states for TSC.  We
>> should just having a table assuming that the TSC is safe to use in SMP
>> environments and gets rid of any other flag (in this case, for amd64
>> based machine, the logic could, for example, check if the CPU is P
>> state invariant and assume it is safe, etc.)
>
> No, these are two entirely different things.  An SMP-safe TSC is a TSC
> that is synchronized across cores / packages.  A P-state invariant TSC
> is a TSC that does not vary with the CPU frequency.  One does not imply
> the other, and in many cases (if not most), there is no way to detect
> programmatically that the TSC is SMP-safe or P-state invariant or both.

But I'm not saying they are the same at all.
What I'm saying is that we should just have a whitelist of allowed
architectures with valid TSC (not affected by any problem) and allow
TSC as default timecounter for that.
If we, additively, wants to export informations about the TSC (is it
Pstate invariant? is it smp invariant in freq for smp? etc) we can do
with a bitfield.
In order to determine if a TSC works or not we could start with a
testing suite, involving ACPI states changing and test TSC variations.

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein