This is the right approach, IMHO. Let me run local apps like video rendering and transcoding using all cores, but let me mark anything that has Internet access as only executing on a dedicated core.

Apple's new hardware approach might work well for this: on the A12X chip used by the new iPad Pro, they have 4 high performance cores and 4 low power cores. Let Chrome have a couple low power cores, and that solves a few problems:

1. I get security isolation between Chrome and the rest of my apps. 2. I no longer care very much when poorly written javascript wants to consume 100% of CPU because it's only running on a low power core. 3. My battery life is also better because Chrome can't consume a high power core.

It should be possible to do the same thing on anything that supports CPU frequency scaling. Tell the OS that the core the browser is running on should only run at the lowest supported frequency. Or only allow it to run at higher frequency if it hasn't been active for more than 15 of the last 60 seconds.

FYI Apple didn't come up with the idea of having differing cores: https://en.wikipedia.org/wiki/ARM_big.LITTLE

Unfortunately this contention is the exact reason this isn't done. Similar workloads (from the same program) will perform poorly in the same SMT groups. You can try this in windows using the core affinity of processes. You'll find that when one application shares both HTs it will perform much worse.

Under optimal conditions (rendering) enabling SMT on Intel gives just ~30% extra performance, ~40% on AMD (usually much less), so of course you can't compare the additional thread provided by SMT to a thread running on another, otherwise idle core.

Scheduling only threads of the same process on a SMT group at a time is the easiest portsmash mitigation while still retaining some of the SMT peformance benefit.