non-invariant tsc and cputicker

[Jung-uk Kim]

On Monday 06 December 2010 02:38 pm, Andriy Gapon wrote:
> 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?

CPU ticker is per-CPU property, not global.  So, it is okay even if it 
cannot be used as a timecounter backend.  If TSC is selected as a 
timecounter source, that means a) it is a P-state invariant UP system 
or b) the user forced it.  If the CPU is P-state invariant, it does 
not matter it is UP or SMP because it is per-CPU property.  If the 
CPU is not invariant or UP system, then it does not allow frequency 
changes as you've noticed.  If the user forced it on SMP, well, the 
user should know its consequence. ;-)

> >> 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.

But most of our users do have old hardware, unfortunately.

> > 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.

AFAIK, multi-core/single-package/single-socket systems have usually 
P-state invariant TSCs already, i.e., it can be used as a CPU ticker 
naturally.

> I tested only one two-socket machine from perf-cluster and it had
> more or less "SMP-correct TSC" too.

Unfortunately "more or less" does not work for us because timecounter 
should never go backwards.  It MUST be monotonic.

> BTW:
> http://people.freebsd.org/~avg/tsc/

Interesting...  I've seen something like this in the past.  In fact, 
I've written my own long ago but I wasn't able to make it 100% 
correct, unfortunately. :-(

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

No, it is not.  Sorry, if I confused you somehow.

Jung-uk Kim