On 3/25/11 1:24 AM, Peter Jeremy wrote:
On 2011-Mar-24 17:00:02 +0800, Jing Huang<jing.huang....@gmail.com> wrote:
In this scenario, I plan to use both tsc and shared memory to
calculate precise time in user mode. The shared memory includes
system_time, tsc_system_time and factor_tsc-system_time.
This sounds like a reasonable approach to me. Note that once we
implement a shared page, there is probably a variety of other
information we could usefully place on that page.
SunOS 4.x included a page of shared memory per CPU. This was mapped
as an array (indexed by CPU number) at one address and the page
reflecting the current CPU was additionally mapped at another fixed
address. This allowed a process to both refer to data on its CPU
as well any CPU on the system.
We also consider the CPU frequency, because tsc counter is
related to it. When kernel changes CPU frequency, the shared memory
should be update subsequently.
Two issues with this, particularly on x86 without invariant TSC:
- looking up the current CPU frequency may not be a cheap operation
- the reported CPU frequency appears to be just an approximate value,
rather than the actual TSC frequency.
On 2011-Mar-24 21:34:35 +0800, Jing Huang<jing.huang....@gmail.com> wrote:
As I know, tsc counter is CPU specific. If the process running on
a multi-core platform, we must consider switching problem. The one
way, we can let the kernel to take of this. When switching to another
CPU, the kernel will reset the shared memory according to the new CPU.
I'm not sure what the cost of managing this page mapping will be.
The second way, we can use CPUID instruction to get the info of
current CPU, which can be executed in user mode ether. At the same
time, the kernel maintains shared memory for each CPU. When invoke
gettimeofday, the function will calculate precise time with current
CPU's shared memory.
This approach suffers from a race condition between the CPUID
instruction and accessing the appropriate shared page - there is the
potential for an interrupt causing the process to be switched to a
different CPU, resulting in an incorrect page being accessed.
The shared page(s) can be in the form of an elf module that is linked
with the process at load time.
that way you can put cpu-specific code snippets there as well.
when using a shared page to modify the TSC value read, one also needs to
tempirarily lock the cpu you are on between the time you read the
calibration value and
the time you read the TSC.. A user process has only limited ability to
do that.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
