* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> Andrew,
>
> could we try this one in -mm? It unifies (and simplifies) the TSC sync
> code between i386 and x86_64, and also offers a stronger guarantee
> that we'll only activate the TSC clock on CPU where the TSC is synced
> correctly by the
* Ingo Molnar [EMAIL PROTECTED] wrote:
Andrew,
could we try this one in -mm? It unifies (and simplifies) the TSC sync
code between i386 and x86_64, and also offers a stronger guarantee
that we'll only activate the TSC clock on CPU where the TSC is synced
correctly by the hardware.
On Fri, 24 Nov 2006, Andi Kleen wrote:
> The trouble is that people are using the RDTSC anyways even if the
> kernel doesn't. So some synchronization is probably a good idea.
It is better to simply leave TSC alone if unsynchronized. If TSCs appear
to be in sync (through some sporadic
Using gtod() can amount to a substantial disturbance of the thing to
be measured. Using rdtsc, things seem reliable so far, and we have an
FPGA (accessed through the PCI bus) that has been programmed to give
access to an 8MHz clock and we do some checks against that.
Same here.
The difference that Wink reports is tiny compared to that measured on
my Opteron machines:
dual (2.6.17):
[EMAIL PROTECTED]:cyclecounter_test$ ./rdtsc-pref 100
rdtsc: average ticks= 10
gtod:average ticks=4296
gtod_us: average ticks=4328
quad (2.6.16-rt29):
[EMAIL
Arjan van de Ven wrote:
just to make sure, you do realize that when you write "ticks" that rdtsc
doesn't measure cpu clock ticks or cpu cycles anymore, right? (At least
not on your machine)
Yes, that's why I wrote ticks and not cycles. At this point I'm not sure how to
convert
ticks to time
Arjan van de Ven wrote:
just to make sure, you do realize that when you write ticks that rdtsc
doesn't measure cpu clock ticks or cpu cycles anymore, right? (At least
not on your machine)
Yes, that's why I wrote ticks and not cycles. At this point I'm not sure how to
convert
ticks to time
The difference that Wink reports is tiny compared to that measured on
my Opteron machines:
dual (2.6.17):
[EMAIL PROTECTED]:cyclecounter_test$ ./rdtsc-pref 100
rdtsc: average ticks= 10
gtod:average ticks=4296
gtod_us: average ticks=4328
quad (2.6.16-rt29):
[EMAIL
Using gtod() can amount to a substantial disturbance of the thing to
be measured. Using rdtsc, things seem reliable so far, and we have an
FPGA (accessed through the PCI bus) that has been programmed to give
access to an 8MHz clock and we do some checks against that.
Same here.
On Fri, 24 Nov 2006, Andi Kleen wrote:
The trouble is that people are using the RDTSC anyways even if the
kernel doesn't. So some synchronization is probably a good idea.
It is better to simply leave TSC alone if unsynchronized. If TSCs appear
to be in sync (through some sporadic
On Sun, 2006-11-26 at 11:48 -0800, Wink Saville wrote:
> Arjan van de Ven wrote:
> > it's the cost of a syscall (1000 cycles?) plus what it takes to get a
> > reasonable time estimate. Assuming your kernel has enough time support
> > AND your tsc is reasonably ok, it'll be using that. If it's NOT
Arjan van de Ven wrote:
it's the cost of a syscall (1000 cycles?) plus what it takes to get a
reasonable time estimate. Assuming your kernel has enough time support
AND your tsc is reasonably ok, it'll be using that. If it's NOT using
that then that's a pretty good sign that you can't also use
On Sun, 2006-11-26 at 00:16 -0800, Wink Saville wrote:
> Robert Hancock wrote:
> Actually, we need to ask the CPU/System makers to provide a system wide
> > Generally user mode code should just be using gettimeofday. When the TSC
> > is usable as a sane time source, the kernel will use it.
Robert Hancock wrote:
Actually, we need to ask the CPU/System makers to provide a system wide
Generally user mode code should just be using gettimeofday. When the TSC
is usable as a sane time source, the kernel will use it. When it's not,
it will use something else like the HPET, ACPI PM Timer
Robert Hancock wrote:
Actually, we need to ask the CPU/System makers to provide a system wide
Generally user mode code should just be using gettimeofday. When the TSC
is usable as a sane time source, the kernel will use it. When it's not,
it will use something else like the HPET, ACPI PM Timer
On Sun, 2006-11-26 at 00:16 -0800, Wink Saville wrote:
Robert Hancock wrote:
Actually, we need to ask the CPU/System makers to provide a system wide
Generally user mode code should just be using gettimeofday. When the TSC
is usable as a sane time source, the kernel will use it. When it's
Arjan van de Ven wrote:
it's the cost of a syscall (1000 cycles?) plus what it takes to get a
reasonable time estimate. Assuming your kernel has enough time support
AND your tsc is reasonably ok, it'll be using that. If it's NOT using
that then that's a pretty good sign that you can't also use
On Sun, 2006-11-26 at 11:48 -0800, Wink Saville wrote:
Arjan van de Ven wrote:
it's the cost of a syscall (1000 cycles?) plus what it takes to get a
reasonable time estimate. Assuming your kernel has enough time support
AND your tsc is reasonably ok, it'll be using that. If it's NOT using
Wink Saville wrote:
Arjan van de Ven wrote:
Actually, we need to ask the CPU/System makers to provide a system wide
timer that is independent of the given CPU. I would expect it quite
simple
they exist. They're called pmtimer and hpet.
pmtimer is port io. hpet is memory mapped io.
Thanks
Wink Saville wrote:
Arjan van de Ven wrote:
Actually, we need to ask the CPU/System makers to provide a system wide
timer that is independent of the given CPU. I would expect it quite
simple
they exist. They're called pmtimer and hpet.
pmtimer is port io. hpet is memory mapped io.
Thanks
20 matches
Mail list logo
