Intel Core 2 Duo (Merom)
Available Types and ThinkPads featuring them
|Name||sSpec||Frequency (MHz)||L2 Cache||FSB (MHz)||VT||core Voltage (V)||TDP (W)||ThinkPad Models|
|max.||min.||high||low||high freq||low freq|
|T7700||2400||1000||4MB||800||yes||1.30||0.85-0.9||35||?||R61, T61, T61p|
|T7500||2200||1000||4MB||800||yes||1.30||0.85-0.9||35||?||R61, T61, X61|
|T7400||SL9SE||2166||1000||4MB||667||yes||1.30||0.95||34||20||T60, T60p, Z61t|
|T7300||2000||800||4MB||800||yes||1.30||0.85-0.9||35||?||R61, T61, X61|
|T7200||SL9SF||2000||1000||4MB||667||yes||1.30||0.95||34||20||R60, T60, X60, Z61m, Z61t|
|T5600||1833||1000||2MB||667||yes||1.30||0.95||34||20||R60, T60, X60, Z61t|
|T5500||1666||1000||2MB||667||no||1.30||0.95||34||20||R60, T60, X60, Z61m, Z61t|
|Nr.||Frequency (MHz)||L2 Cache||FSB (MHz)||VT||core Voltage (V)||TDP (W)||ThinkPad Models|
|max.||min.||high||low||high freq||low freq|
|L7400||1500||1000||4MB||667||yes||1.2||0.85 - 0.9||17||?||X60s, X60 Tablet|
|L7500||1600||800||4MB||800||yes||1.1||0.85 - 0.9||17||?||X61s, X61 Tablet|
|L7700||1800||800||4MB||800||yes||1.1||0.85 - 0.9||17||?||X61s, X61 Tablet|
|SL7100||1200||800||4MB||800||yes||1.1||0.85 - 0.9||12||?||X300|
As you can see, the Low-Voltage CPU's work at the same Voltage as the normal CPUs when running in SLFM. With a simple tool (RMClock) you can use those lower voltages at every clock. Intel gave other voltage-regions for the CPUs:
the standard processor that works on a core voltage between 1.075V and 1.175V, the low voltage processors that work between 0.975V and 1.062V and finally the ultra low voltage processors that work between 0.80V and 0.975V.
Intel doesn't think of the SLFM. With SLFM and a little bit luck, you're T-CPU can be thriftier than a LV-CPU but has more power. With RMClock every T-CPU is thriftier than a LV-CPU, because you have the same voltage but a higher max-clock, so the sleep-states can be longer.
The maximum temperature for safe operation is 100°C.
The catastrophic thermal protection temperature is 125°C.
Idle temperature is typically around 30-50°C.
Temperature at full utilisation is around 60-70°C.
These latter two values will of course depend largely on cooling systems and available airflow.
Compiler optimisation flags
In addition to the architecture independent
-O[0123s] option hierarchy, architecture dependent optimisations are controlled by the
-mtune=<cpu-type> options. The <cpu-type> argument (not surprisingly) describes the type of cpu for which to optimise the compiled code. The
-mtune option will generate code that is optimised for the given cpu type which will nevertheless run on cpu types other than the optimisation target. On the other hand,
-march will attempt to optimise more aggressively at the expense of reducing portability to other cpu types. Optimisations implied by
-mtune are a subset of
-march optimisations, and thus it is only necessary to specify
-march if the the maximum level of optimisation is desired.
With version of gcc before 4.3, 32-bit code should be compiled with the "prescott" as the cpu-type argument to
-mtune whereas 64-bit code should use the "nocona" argument. Gcc 4.3 however introduces "core2" as a valid argument to the
-march options which should be used. Alternatively, as of gcc 4.2, the "native" argument is supported. This will automatically determine the cpu-type on which compilation is taking place and apply optimisations specific to that cpu.
For the SPEC CPU 2006 benchmarks, Intel used the shorthand
-fast, which translates into
-O3 -ipo -static -no-prec-div -xP. However, the compiler also provides the flag
-xT, which activates the optimization for Core 2 Duo and SSSE3 (instead of SSE3 only with
Much like software products, bugs, errata or ways to improve upon operation are often found in CPU's after they have reached the market. In some cases, the necessary changes can be applied by the end user without any change to the underlying hardware in the form of microcode updates downloadable from the manufacturer. Intel offers these microcode updates for download on their website.
Provided the availability of the microcode and firmware kernel modules (which are enabled in the stock kernels of most distributions) and a suitable user space tool such as microcode_ctl, one can install the updated microcode into their processors at runtime. The microcode update is volatile however, meaning that it disappears upon reboot. While this reduces the risk of applying such an update to essentially 0, it does mean that it must be applied on each boot.
You can install the microcode.ctl package which will take care of everything (including downloading the microcode itself) for you. Just run
# aptitude install microcode.ctl. This package includes an init script which will run at boot to load the microcode into the processor. This script also contains a line which will remove the microcode kernel module once the operation is complete and it is no longer needed, however it is strangely commented out by default. If you want to keep your loaded modules (used memory) to a minimum, you can edit /etc/init.d/microcode.ctl and uncomment the line
[ -x /sbin/modprobe ] && /sbin/modprobe -r microcode > /dev/null 2> /dev/null
The microcode-ctl utility can be installed as follows:
# emerge microcode-ctl. This will create an init script /etc/init.d/microcode_ctl, but will not automatically set it to run on startup; to do so, run
# rc-update add microcode_ctl boot. Also, this will install an old copy of the microcode to /etc/microcode.dat; to update it, download a new copy from the link above and replace this file.
Note on Hyper-Threading
Note that as opposed to Pentium 4/NetBurst, current Core 2 do not support hyper-threading, and therefore there is usually no option in the BIOS to activate it. Refer to Intel's Hyper-Threading Technology for a list of hyper-threading capable CPU.