Date: Sun, 27 Mar 2011 21:29:40 -0700 From: Julian Elischer <julian@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: kostikbel@gmail.com, freebsd-hackers@freebsd.org, Jing Huang <jing.huang.pku@gmail.com> Subject: Re: [GSoc] Timeconter Performance Improvements Message-ID: <4D900EB4.2050500@freebsd.org> In-Reply-To: <703A54EA-3C99-4BAF-923B-91B50BFFC748@bsdimp.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> <703A54EA-3C99-4BAF-923B-91B50BFFC748@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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<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.
>>>> 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-unsubscribe@freebsd.org"
>>
>>
> _______________________________________________
> 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"
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D900EB4.2050500>