Re: non-invariant tsc and cputicker

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

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!

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

-- 
Andriy Gapon