On 3/27/11 3:32 PM, Warner Losh wrote:
On Mar 26, 2011, at 8:43 AM, Jing Huang wrote:
Hi,
Thanks for you all sincerely. Under your guidance, I read the
specification of TSC in Intel Manual and learned the hardware feature
of TSC:
Processor families increment the time-stamp counter differently:
• For Pentium M processors (family [06H], models [09H, 0DH]); for Pentium 4
processors, Intel Xeon processors (family [0FH], models [00H, 01H, or 02H]);
and for P6 family processors: the time-stamp counter increments with every
internal processor clock cycle.
• For Pentium 4 processors, Intel Xeon processors (family [0FH],
models [03H and
higher]); for Intel Core Solo and Intel Core Duo processors (family [06H], model
[0EH]); for the Intel Xeon processor 5100 series and Intel Core 2 Duo processors
(family [06H], model [0FH]); for Intel Core 2 and Intel Xeon processors (family
[06H], display_model [17H]); for Intel Atom processors (family [06H],
display_model [1CH]): the time-stamp counter increments at a constant rate.
Maybe we would implement gettimeofday as fellows. Firstly, use cpuid
to find the family and models of current CPU. If the CPU support
constant TSC, we look up the shared page and calculate the precise
time in usermode. If the platform has invariant TSCs, and we just
fallback to a syscall. So, I think a single global shared page maybe
proper.
I think that the userspace portion should be more like:
int kernel_time_type) SECTION(shared);
struct tsc_goo tsc_time_data SECTION(shared);
switch (kernel_time_type) {
case 1:
/* code to use tsc_time_data to return time */
break;
default:
/* call the kernel */
}
I think we should avoid hard-coding lists of CPU families in userland. The
kernel init routines will decide, based on the CPU type and other stuff if this
optimization can be done. This would allow the kernel to update to support new
CPU types without needing to churn libc.
Warner
P.S. The SECTION(shared) notation above just means that the variables are in
the shared page.
As has been mentioned here and there, the gold-standard way for doing
this is for the kernel to export a special memory region
in elf format that can be linked to with exported kernel sanctioned
code snippets specially tailored for the cpu/OS/binray-format
in question. There is no real security risk to this but potential
upsides are great.
On Sat, Mar 26, 2011 at 10:12 PM, John Baldwin<j...@freebsd.org> wrote:
On Saturday, March 26, 2011 08:16:46 am Peter Jeremy wrote:
On 2011-Mar-25 08:18:38 -0400, John Baldwin<j...@freebsd.org> wrote:
For modern Intel CPUs you can just assume that the TSCs are in sync across
packages. They also have invariant TSC's meaning that the frequency
doesn't change.
Synchronised P-state invariant TSCs vastly simplify the problem but
not everyone has them. Should the fallback be more complexity to
support per-CPU TSC counts and varying frequencies or a fallback to
reading the time via a syscall?
I think we should just fallback to a syscall in that case. We will also need
to do that if the TSC is not used as the timecounter (or always duplicate the
ntp_adjtime() work we do for the current timecounter for the TSC timecounter).
Doing this easy case may give us the most bang for the buck, and it is also a
good first milestone. Once that is in place we can decide what the value is
in extending it to support harder variations.
One thing we do need to think about is if the shared page should just export a
fixed set of global data, or if it should export routines. The latter
approach is more complex, but it makes the ABI boundary between userland and
the kernel more friendly to future changes. I believe Linux does the latter
approach?
--
John Baldwin
_______________________________________________
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"
_______________________________________________
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"
_______________________________________________
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"
