Hacker News Reader

Comment by BeastMachine | Hacker News Reader

While you can't explicitly allocate a process to E cores, I wonder if you'd be able to make a program which floods high QoS processes to saturate E cores until they are full and then launch the desired application into a P core

View on HN

This is a similar hack to what AMD does with their new 3D-series processors with two CCDs (or clusters following this article's terminology). One of them has a higher clock count but the other one has much more L3 cache. Since their target is gamers (at least at the consumer level chips), they basically ship a driver which detects when you launch a game and "parks" the low-cache CCD from being assigned tasks which effectively dispatches your processes to the high-cache ccd.

EPYC SKUs with 3D cache also exist. Though I’m not 100% sure if it uses heterogenous chiplet approach that is seen in consumer RYZEN chips.

I'm not sure I see the point? Applications generally run on P cores by default; there's no need to go through those sorts of gymnastics to make that happen.

On my M2 Macbook Air, I see everything generally executes on the E-cores. The P-cores only see load when there's clearly something that needs lots of processing power.

I presume there's logic in the scheduler to prioritize E-cores for battery life purposes.

No. Application with low priority will only be scheduled on efficiency cores regardless of how oversubscribed they are.

You can't set a process's processor affinity (aka which core(s) the process will execute on)?

I don't think it's completely guaranteed that you can choose such things anymore. Some scheduling work has to be done at the hardware level and it's certainly going to be hijacked as heterogeneous CPU micro architecture becomes more pervasive and the gulf of difference in feature set between efficiency and performance cores becomes wider.

This is not exposed on production systems.

Reply on news.ycombinator.com