non-invariant tsc and cputicker
Andriy Gapon
avg at freebsd.org
Mon Dec 6 18:40:34 UTC 2010
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
More information about the freebsd-current
mailing list