Ok, to clarify the issues seen with overclocking... (tl;dr warning)
Well, with minimal OC's, I'd expect (miniscule) performance gains to be relatively unhindered. A meager .4 Ghz would likely be fine. However, above that would likely begin to cause speedstepping issues.
OC issues degrade performance in these proc's by means of the CPU spamming itself with C1E/C6 interrupts. Nehelem/Westmere PCU (not a typo - Power Control Unit) has the ability to override OS/ACPI/APIC requests with its own instructions unless you turn off power staging in your BIOS... and level of control in that regard differs greatly from one mobo to another.
Speedstepping technically goes back to the Pentium-3 (even in the desktop variants though laptops had far more control) and in the Core & Core2 era gained a fair amount of control over not just clock (c-states) but also voltage (p-states or power.) Technically this is supposed to work via ACPI (via the hardware APIC controller) and is under OS control, but bios profiles already had the ability to override ACPI/OS power control (by reducing the features available) and so technically supersedes it. Normally at the very least a cpu core has 2 states: C0 (active) and C1 (idle, no work) but in the 'old' cpu's (going back to the Pentium 2/3) more idle states were introduced which gave the ability to reduce power and even disable portions of the cpu (cache and so on) as the sleep got 'deeper'. With Pentium-M (in mobile form) and the Core/Core2 era the C-states were expanded to cover C0 through C5 (5 sleep levels) and several P-states, but even in C5 cores were active.
Now, with the addition of a C6 state (referred to as "core-parking"), the core basically SHUTS OFF. Switching back from this state takes much longer than the other preceding levels. Nehelem also added more voltage control ("Enhanced" EIST) and brings a new C1 state called C1E, which means that the cpu can throttle voltage even in the first sleep state now (which wasn't possible before).
Interestingly, with Nehelem Intel technically went 'backwards' a bit and created a 486-sized chunk of on-chip PLL-based logic to control power states. Now, in addition to throttling cores (with effects on their shared cache), this opened up the door to a lot more.
Unfortunately, this also means the Nehelem PCU (again, not a typo) can override OS (and ACPI) level settings if it thinks it has a better idea of how to save power AND/OR use resources for turbo on a core or two. Ie, turbo is completely transparent to the OS and many of the C-state changes (to lower 'sleep' states) may occur even if you set power profiles in the OS to be high performance. Incidentally you don't have "as much" control over power profiles in windows, but the main overall power profiles DO engage different cpu & hardware features (Mobile, Desktop Balanced, Desktop Power saving & Desktop High Performance are the most common on Win7) and you can dig in and customize cpu & hardware power saving features under each plan.
OC'ing may in fact disable certain features (Turbo or advanced sleep states that use a combination of P & C states) since you're interacting (at the very least) with the default p-states (voltage) and the thermal envelope (voltage=heat). Turbo modes are dependent on a cpu staying within its overall operating specs or TDP (turbo works by adjusting the multiplier up 1-2 steps depending on how much 'headroom' the PCU thinks there is.) So at the very least overclocking may affect turbo modes (and I know for a fact that on some motherboards using a more aggressive overclocking profile disables turbo, but this I suspect is VENDOR or at least BIOS specific). But when ignoring overclocking features, there seems to be a lot of variety on what BIOS makers (and the motherboard makers who customize the bios) are exposing for end-user control over C-states & P-states. You might be able to control all C & P states individually (including even specifying voltages if you're overclocking) with allowance of control.
Of course, disabling Turbo is generally the suggested precursor to OC'ing. However, this only disallows the possibility of
some C6 interrupts. Also, there is no guarantee that BIOS-level (certainly not OS) control can completely preempt PCU instructions (as I hinted earlier).
So, keeping Turbo in mind, look back to the cases where the first sleep state (C1) and the lower sleep states (especially C6) are affecting cpu performance for applications that rely on raw performance. There are several factors here again, the first of which is how long sleep states C1 through C6 take to wake up. Reference this
Xbit labs section on "Power Management and Turbo Mode" in their "First Look at Nehalem Microarchitecture" article, and
check this table. Look at the row for 'wakeup time' and also take note of the part that says "Core Caches=flushed" for C3 through C6 after that. This alone has enough impact on performance that when using a machine in a heavy session, disabling speedstepping/EIST altogether can gain as much performance (if not more) as overclocking can, simply by insuring that all parts of the cpu are online at all times. Now add on the fact that even when you are manually disabling things, Nehelem's PCU has the ability to still decide what to do...
But things seem to be even more interesting with C1E & C6 specifically....
There seem to be several cpu-errata with all the Nehelem cpu's in regards to handling of C6 (look up Bloomfield's errata list and check for 'spurious interrupts' in the pdf). There seems to be cases where idle cores actually spam so many interrupts that they were throttling network performance on Xeon machines (where the PCI/PCIe bus's sensitivity to having access to the cpu via interrupt requests shows issues that casual users should, in theory, never notice). What this means is that the Power Control Unit on Nehelem era cpu's (and now Westmere) has the ability to generate interrupts that are handled BEFORE most items on the PCI & PCIe bus (they're a higher priority). So, when the PCU decides a core needs to sleep before the handling of the i/o is done, and, if the core needs to be brought back online, this of course generates yet another interrupt which again prevents the handling of the i/o interrupt... and handling continually degrades.
As for C1E, there seems to also be an effect on the IRQ traffic generated for the 'highest level' of sleep on nehelem (the p-state as well as c-state change that occurs seems to degrade audio i/o & bus-dependant system performance more than the older 'C1' states that existed before nehelem). So, the recommendations right now from system builders are to disable C1E & C6 (or just disable speedstepping & Enhanced EIST in your BIOS)
provided you know your cooling system is adequate AND your system's airflow is sufficient. This is incredibly important for people, like myself, that handle a large number of audio tracks concurrently at low latencies stacked on top of the scheduling necessities of plugin use.
Even Mac users were noticing issues... and it showed up with an application as simple as iTunes... when doing simple audio playback, something was sending core temps in the extremes regardless of the fact that not much cpu usage was technically occuring. And while Apple issued a patch
with the usual lack of technical info, the timing just happened to be coincident with a patch from MS for Server2008 that addressed a similar issue with networking & C6-sleep states colliding when cores were parking (lulz). The solution in both cases (before the patches) was to disable C6 (and C1E for other reasons), but of course you can't do that on a Mac since you don't have access to BIOS style features with Apple's EFI implementation so...
Outside of those user groups, the number of audio & networking/raid users affected by the C6 'core parking' issue was not significant enough for either MS or even the tech review sites to have caught on. But there are a few audio builders (yours truly;)) and Mac users who are aware of the effect that C1E/C6 had on their performance, and now I've seen discussion on every music forum I frequent about it (since this is our current generation). However, what is lacking is consensus. Each BIOS offers different features, and overclocking features seem to expose even more (different) features... so there's little consensus on what the 'best' approach actually is: Disable C6; Disable C1E & C6 but leave turbo active; or disable everything altogether to leave the cpu in a single but very predictable/reliable state.
So it's not overclocking PER SE that will degrade performance, but different overclocking features might be exposed that affect what you see differently. And, regardless of whether you do or do not OC, C6 (and C1E) seem to have a degrading effect on users who are pushing their systems the furthest.
Whew! That's gotta be my longest post I've ever written on BBT... definitely not my longest ever, tho.
