Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

On Sun, Mar 29, 2009 at 2:07 PM, Peter Jeremy
<peterjeremy@xxxxxxxxxxxxxxxx> wrote:
On 2009-Mar-27 14:19:16 -0400, Alexander Sack <pisymbol@xxxxxxxxx> wrote:
I'm assuming folks are still in love with the TSC because it still the
cheapest as oppose ACPI-fast or HPET to even contemplate this?

That is its major advantage.  It might be feasible to export all the
data necessary to implement the complete CLOCK_*_FAST family.

Understood.

Also I thought at least PHK's comment (Sergey mentioned it) was true
regardless of bus, that the TSC is not consistent across multiple
packages (and for that matter I suppose cores) due to I *think* its
ISA lineage so how does this work again?

TSC is nothing to do with ISA.  The easiest way to build a counter
that runs at CPU clock rate is to put it very close to the CPU/core
and have different counters for each CPU/core, without any
synchronisation between the different counters.

Understood thanks. I don't know why ISA and TSC are in my head. Please excuse.

 Won't the rate in which you
tick up be sporadic over the course of the process scheduled on
different cores?  (i.e. depending on what core RDTSC happened to land
on)

RDTSC will wind up on the same core that your thread of execution is
running on and this is defined by the scheduler.  IE, it's up to the
scheduler to ensure that the correct page of global (or per-cpu) data
is mapped.

OK. But then why not do what I *think* Solaris does in the first
place, sync the cores using a master/slave to effectively create an
invariant TSC i.e if you are going to buy the overhead in the
scheduler why not do the dirty work at the source instead of all this
overhead in either the scheduler or the logic to know that this thread
of execution was on that core and is using this TSC etc. etc.

I believe this topic has been re-hashed before I don't remember the
outcome so again excuse... :D

Thanks!

-aps
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Improving the kernel/i386 timecounter performance (GSoC proposal)
    ... gettimeofday is likely to be a mixture of global and per-core data so ... packages (and for that matter I suppose cores) due to I *think* its ... synchronisation between the different counters. ... running on and this is defined by the scheduler. ...
    (freebsd-current)
  • Re: Improving the kernel/i386 timecounter performance (GSoC proposal)
    ... gettimeofday is likely to be a mixture of global and per-core data so ... packages (and for that matter I suppose cores) due to I *think* its ... synchronisation between the different counters. ... running on and this is defined by the scheduler. ...
    (freebsd-hackers)
  • Re: Improving the kernel/i386 timecounter performance (GSoC proposal)
    ... packages (and for that matter I suppose cores) due to I *think* its ... TSC is nothing to do with ISA. ... synchronisation between the different counters. ... running on and this is defined by the scheduler. ...
    (freebsd-current)
  • [patch 1/] timers: tsc using for cpu scheduling
    ... uses jiffies_64 for process priority calculation instead of Time Stamp ... Clock (TSC). ... process which provoke to memory threshing and bad cpu and cash using has ... But for scheduler purposes the value of work ...
    (Linux-Kernel)
  • summary (Re: [patch] prefer TSC over PM Timer)
    ... and attempted to summarize the ... if timer_pm is fixed to read the PM timer only once on non-broken systems ... until/unless C3 and deeper resync tsc then it's best not to default to tsc ... can't be shared with scheduler if we add variable scheduler ticks ...
    (Linux-Kernel)