Date: Sun, 27 Mar 2011 16:32:50 -0600 From: Warner Losh <imp@bsdimp.com> To: Jing Huang <jing.huang.pku@gmail.com> Cc: kostikbel@gmail.com, freebsd-hackers@FreeBSD.org, John Baldwin <jhb@FreeBSD.org> Subject: Re: [GSoc] Timeconter Performance Improvements Message-ID: <703A54EA-3C99-4BAF-923B-91B50BFFC748@bsdimp.com> In-Reply-To: <AANLkTimjj6dimyoY1K4xKabiNeAMjSt-YXjFpdaTJCTr@mail.gmail.com> References: <AANLkTimbBohQmoPv19Qq2U6M70OBx%2BFBMiUAzQmqrTLK@mail.gmail.com> <201103250818.38470.jhb@freebsd.org> <20110326121646.GA2367@server.vk2pj.dyndns.org> <201103261012.32884.jhb@freebsd.org> <AANLkTimjj6dimyoY1K4xKabiNeAMjSt-YXjFpdaTJCTr@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 26, 2011, at 8:43 AM, Jing Huang wrote:
> Hi,
>=20
> Thanks for you all sincerely. Under your guidance, I read the
> specification of TSC in Intel Manual and learned the hardware feature
> of TSC:
>=20
> Processor families increment the time-stamp counter differently:
> =95 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.
>=20
> =95 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.
>=20
> 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.
>=20
>=20
> On Sat, Mar 26, 2011 at 10:12 PM, John Baldwin <jhb@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 <jhb@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.
>>>=20
>>> 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?
>>=20
>> 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).
>>=20
>> 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.
>>=20
>> 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?
>>=20
>> --
>> John Baldwin
>>=20
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to =
"freebsd-hackers-unsubscribe@freebsd.org"
>=20
>=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?703A54EA-3C99-4BAF-923B-91B50BFFC748>