non-invariant tsc and cputicker

[Andriy Gapon]

on 06/12/2010 21:27 Jung-uk Kim said the following:
> On Monday 06 December 2010 02:09 pm, Andriy Gapon wrote:
>> on 06/12/2010 21:01 Jung-uk Kim said the following:
>>> :-) Don't get me wrong, I generally agree with you *iff* it does
>>> : not
>>>
>>> hurt too much.  Anyway, this issue should be resolved from the
>>> root, i.e., kern_resouce.c, if possible.
>>
>> But what to resolve there?
> 
> Better algorithm for stat.
> 
>> I just want to always have a stable source "cpu ticks", and then
>> everything else should just work?
> 
> If we had one, yes.  But we don't, at least for old x86 hardware. :-(

This sounds contradictory... I don't follow.
So, TSC as a direct source of cpu ticks is good enough, but TSC as a source for
timecounter acting as a source for cpu ticks is not stable?

>> BTW, if someone comes up with a patch for more or less correct
>> accounting when "cpu ticks" frequency is allowed to change, then I
>> am all for it. But, IMO, it's just easier to use stable "cpu
>> ticks".
> 
> If it doesn't hurt too much, yes.  Remember the P-state invariant CPUs 
> are pretty new.

Well, not that new in this fast changing world.

> SMP-correct TSC is quite rare if there is any.

This contradicts my experience. All systems that I could test have "SMP-correct
TSC".  Yes, they all are 1-2 years old and they all are single-package multi-core
 systems.  I tested only one two-socket machine from perf-cluster and it had more
or less "SMP-correct TSC" too.
BTW:
http://people.freebsd.org/~avg/tsc/

But, this SMP-correctness is not a requirement for the cpu ticks accounting that
we are discussing, right?

-- 
Andriy Gapon