non-invariant tsc and cputicker
jkim at FreeBSD.org
Mon Dec 6 19:01:31 UTC 2010
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
> >>> http://svn.freebsd.org/viewvc/base?view=revision&revision=15553
> >>> 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
:-) 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.
More information about the freebsd-current