Thanks for your reply, but in the mean time I found an almost satisfying solution. Here are my findings:
Originally Posted by erniv2
You cant lock Turbo mode.
To take full advantage of Turbo you have to enable EIST TURBO and C1E in Bios, Turbo Mode only kicks in when the demand is there and the Package allows it to happen, Icore CPUS have a TDP in wich they have to operrate if the CPU exceeds this power needs Turbo wont work.
Well, not exactly... The turbo mode can kick in whether C1E (which is just an enhanced C1 state, that is, a HALT state) is available or not. You can disable all C states but C0 (which is the 100% non-idle state) and still use the turbo mode, as long as the package TDP is not exceeded (and the TDP itself can be tweaked from the BIOS via the max intensity settings in both non-turbo and turbo modes, so in fact, you can have turbo mode always, excepted when thermal throttling kicks in).
Also things are setup in BIOS and in OS. Linux is more strict about settings it takes basically everything what the BIOS tells it for granted P-states, C-States are taken from ACPI in Linux exept there is a known workaround.
P and C states are two diffrent things also C state happens when Linux thinks no work happens it sends a Idle command to the processor and it compeltly shuts down. P State is a Performance state that is calculated from the average usage over time. P States are just Multipliers of the BCLK.
A CPU has a given range i only can tell it from mine a i5 750 operates in a given range x12 multi to x 20 if all 4 cores work the turbo multi is 21 if 2 work the multi is 24.
If you have a Good BIOS on your board you can set Multis you can set standard x33 3 core x34 2 core x36 1 core x36.
But if you do big overclocks like most do here like 50% they simply disable EIST and Turbo and just set a Fixed Multi+voltage etc fixed so they can get system stable.
If you want EIST and Turbo you have to set Multis manual and Voltage range Manual.
Cant help you with that i dont know what vcore etc. your cpu takes at max.
In fact Linux (tested with v3.4 and v3.5) seems to completely *ignore* the C-state settings in the BIOS (i.e. when all C-states are disabled in the BIOS, Linux is still using them) and also it ignores the change of the multiplier that was set from the BIOS (for example from x33 to x40), using only the hard-coded ACPI P-states for frequency scaling.
Because of the latter reason (hard coded ACPI P-states), I had to disable Intel Enhanced Speedstep from the BIOS, which prevents Linux from using it and from locking the CPU to its stock x33 multiplier (you can also compile the kernel without Speedstep support and it will have the same result than disabling Speedstep from the BIOS).
My motherboard (ASRock Z68 Extreme4 Gen3, flashed with the newest v2.20 BIOS) does allow to set the turbo mode so that all cores go into turbo mode when the latter kicks in (so in fact, as soon as one core starts to get loaded, all cores jump into Turbo mode, which is what I wanted, but I also wanted them to *stay* in Turbo mode to avoid the C-state transitions latency). The turbo mode actually kicks in as soon as you exit the C2/C3/C6 states and "climb" to either C1 or, of course, C0.
I could confirm this with the Linux kernel utility "turbostat" and with i7z
Edit: regarding the Linux stuff, when you compile your kernel yourself do you choose CPU Freq driver ACPI ?
Also wich govener do you choose as standard, there are 3 or 4 diffrent Perfromance and others, maybe you choose the wrong default driver.
I would try with CPUFreqACPI it sould take BIOS orders if that wont work i cant imagine any overclock Turbo to work in Linux.
Like I wrote in my first post, I did have the performance governor compiled and enabled by default. But in fact, like I pointed out above, doing without Speedstep at all was the actual solution...
After many searches I finally found out that it was theoretically possible to disable the ACPI C-states in Linux, by passing a command line parameter to the kernel: "idle=poll" is supposed to disable all C-states but C0 (thus actually never entering HALT mode and keeping polling the kernel scheduler on idle). Or you can supposedly use "processor.max_cstate=1" to limit the C-state switches to C1. Alas, neither works in my case... It's perhaps because I don't compile acpi as a module but built-in instead (I already stumbled on such bugs in Linux where modules parameters were ignored when the module was built into the kernel itself instead of being loaded), or perhaps because the settings get overridden in some way after acpi is initialized, or perhaps because C-states are also switched on other occasions in the kernel than pure "idle" calls... This does look like a bug however, so, time permitting, I might report it as such to the kernel developers.
I my case, the solution was to disable ACPI_PROCESSOR in the kernel at build time: it makes the kernel unaware about C-states (it still uses HALT, but this only switches the CPU to C1, never to C2 or higher, thus actually keeping the CPU core in turbo mode all the time).
It however bothers me, because with ACPI_PROCESSOR disabled, the thermal throttling is no more cared for, and this is of course kind of dangerous (even though I took great care to overclock reasonably and the cores never go over 85°C, which is 20°C below the absolute maximum rating of the Core i5). Because of this, I'll probably patch the kernel acpi driver to hard-code the C1 limit that I can't achieve properly with the "processor.max_cstate=1" parameter, but in the mean time, I did achieve almost everything I wanted (the CPU is now always running at 4.8GHz, i.e. 45 * 106MHz), the only issue being /proc/cpuinfo still reporting 3.5GHz (33 * 106MHz), i.e. ignoring the 45x multiplier that is nonetheless always in force... another bug in Linux...Edited by dinosaur - 9/7/12 at 5:41am