Re: non-invariant tsc and cputicker

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=155444
> > http://svn.freebsd.org/viewvc/base?view=revision&revision=155534
> >
> > 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.

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

> So, I don't think that I propose a dramatic change.

Shrug...  Still I want to see some evidence.

Jung-uk Kim