Date: Tue, 12 Aug 2014 19:35:00 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 192316] Invariant TSC gets misdetected on Intel Core 2 Duo processors, resulting in sluggish system behavior Message-ID: <bug-192316-8-56AxqgLhLA@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-192316-8@https.bugs.freebsd.org/bugzilla/> References: <bug-192316-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192316 John Baldwin <jhb@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Triage |In Discussion CC| |jhb@FreeBSD.org, | |jkim@FreeBSD.org, | |mav@FreeBSD.org --- Comment #2 from John Baldwin <jhb@FreeBSD.org> --- Alexander added the Intel CPUID checks in http://svnweb.freebsd.org/base?view=3Drevision&revision=3D185460 Jung-uk added the AMD CPUID check in http://svnweb.freebsd.org/base?view=3Drevision&revision=3D184146 I think there is some confusion as to what it means to be invariant. The n= ow official definition is "C-, P-, and T-state" invariant. However, the 'tsc_is_invariant' variable only includes 'P- and T-state' invariant, and t= he system even copes with this by disabling Cx states if the TSC is used when = it is not C-state invariant. In terms of what is in the SDM, this is how Intel defines an Invariant TSC = in the February 2014 version of Volume 3 of the SDM includes this quote about = the availability of an Invariant TSC: 17.13.1 Invariant TSC The time stamp counter in newer processors may support an enhancement, refe= rred to as invariant TSC. Processor=E2=80=99s support for invariant TSC is indic= ated by CPUID.80000007H:EDX[8]. The invariant TSC will run at a constant rate in all ACPI P-, C-. and T-sta= tes. This is the architectural behavior moving forward. On processors with invar= iant TSC support, the OS may use the TSC for wall clock timer services (instead = of ACPI or HPET timers). TSC reads are much more efficient and do not incur the overhead associated with a ring transition or access to a platform resource. However, earlier in the text a separate section notes the CPUs that support= a P-state invariant (constant-rate) TSC: Processor families increment the time-stamp counter differently: =E2=80=A2 For Pentium M processors (family [06H], models [09H, 0DH]); for P= entium 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. The internal processor clock cycle is determined by the current core-clock = to bus-clock ratio. Intel=C2=AE SpeedStep=C2=AE technology transitions may als= o impact the processor clock. =E2=80=A2 For Pentium 4 processors, Intel Xeon processors (family [0FH], mo= dels [03H and higher]); for Intel Core Solo and Intel Core Duo processors (family [06= H], 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], DisplayModel [17H]); for Intel Atom processors (family [06H], DisplayModel [1CH]): the time-stamp counter increments at a constant rate. = That rate may be set by the maximum core-clock to bus-clock ratio of the process= or or may be set by the maximum resolved frequency at which the processor is booted. The maximum resolved frequency may differ from the maximum qualified frequency of the processor, see Section 18.14.5 for more detail. On certain processors, the TSC frequency may not be the same as the frequency in the b= rand string. The specific processor configuration determines the behavior. Constant TSC behavior ensures that the duration of each clock tick is uniform and suppor= ts the use of the TSC as a wall clock timer even if the processor core changes frequency. This is the architectural behavior moving forward. I think the problem is that you probably have C1E enabled and so we are not setting 'cpu_can_deep_sleep' in your case. We have special magic for C1E on AMD, but not Intel. And even then, the special magic results in us turning= off the power savings of C1E so it becomes a dumb C1 (as well as explicitly dis= able C3 from being used). I expect most Intel CPUs of this vintage are probably using C1E by default (since it defaults to on in the BIOS), so I would be inclined to basically = go with this patch (but without the AMD changes) and to also remove the TC_FLAGS_C3STOP flag since it will no longer be used (and corresponding cod= e in tc_windup()). This will leave the 'deep_sleep' stuff as only applying to t= he LAPIC timer and not to the TSC. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-192316-8-56AxqgLhLA>