Re: non-invariant tsc and cputicker

On Monday 06 December 2010 01:40 pm, Andriy Gapon wrote:
> on 06/12/2010 20:34 Jung-uk Kim said the following:
> > On Monday 06 December 2010 12:58 pm, Andriy Gapon wrote:
> >> on 06/12/2010 19:42 Jung-uk Kim said the following:
> >>> Sigh...  Please see the history of calcru() in
> >>> sys/kern/kern_resource.c.  Most important ones are:
> >>>
> >>> http://svn.freebsd.org/viewvc/base?view=revision&revision=15544
> >>>4
> >>> http://svn.freebsd.org/viewvc/base?view=revision&revision=15553
> >>>4
> >>>
> >>> Basically, we chose efficiency over accuracy and you are
> >>> suggesting going backwards.
> >>
> >> Well, I guess that it depends.
> >>
> >> Looking at r155444 - the time is still going to be accounted in
> >> ticks (but timecounter ticks).  BTW, I think that this quote
> >> says something: "On more modern hardware no change in
> >> performance is seen." and that was ~5 years ago.
> >
> > "On slower machines, the avoided multiplications to normalize
> > timestams at every context switch, comes out as a 5-7% better
> > score on the unixbench/context1 microbenchmark.  On more modern
> > hardware no change in performance is seen."
> >
> > His performance measurement was done for "the avoided
> > multiplications to normalize timestamps at every context switch",
> > not for "change CPU ticker from tc_cpu_ticks() to cpu_ticks()",
> > which actually happened in r155534 later.
>
> Right.  I was just pointing out a fact.
> That change is not going to get undone anyways.
>
> >> Looking at r155534 - the only change that is going to get undone
> >> is using TSC for the accounting ticks, and that is only for
> >> machines with non-invariant TSC.  And I think that all
> >> sufficiently modern machines have invariant TSC and, in Intel's
> >> words, that's an architectural path going forward.
> >
> > I understand that.  However, it is not clear to me why you want
> > to pessimize performance of old hardware.  If you can convince me
> > old hardware with slow timecounter hardware (e.g., i8254) does
> > not hurt too much, maybe it's okay.
>
> Well, weighing totally bogus stats vs slight stats collection
> pessimization, I have a new proposal - why we don't just hardcode
> some stats values?  That would give that code unbeatable
> performance!

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

> >> So, I don't think that I propose a dramatic change.
> >
> > Shrug...  Still I want to see some evidence.
>
> Evidence of what?
> That nothing is going to be changed for new hardware?
> Or that older hardware won't be slowed down to a crawl?

The latter, kinda.

Jung-uk Kim