Your E-Cores Are Pegged. Your Mac May Be Fine.

Apple silicon can leave its performance cores almost idle while the efficiency cluster sits at 100%. That looks broken because Activity Monitor measures occupied core time, not equivalent work, speed, or energy.

By CoreGuard · Jul 11, 2026 · 11 min read

What does 100% efficiency-core usage mean on a Mac?

It means an efficiency core spent nearly all of the sampling interval executing instructions instead of idling. It does not mean that the Mac used 100% of its total computing power, that an E-core matched a P-core’s throughput, or that something is automatically wrong.

That distinction is the whole article. Activity Monitor displays a reassuringly precise percentage while quietly omitting two variables that matter enormously on Apple silicon: which type of core did the work, and at what frequency?

A full E-core graph beside an empty P-core graph can be exactly what macOS intended. It can also be the visible edge of a stuck indexer, a backup loop, or an app that keeps manufacturing background work. The bars alone cannot decide which.

What % CPU actually measures on Apple silicon

Apple describes CPU usage in Activity Monitor as the percentage of “CPU capability” being used. That wording is convenient and rather too generous.

Howard Oakley’s February 14, 2026 article, “Explainer: % CPU in Activity Monitor,” reports that the number corresponds closely to active residency: the percentage of the sample during which a core was not idle. Activity Monitor adds those per-core values together.

That is why a process can exceed 100%. Roughly speaking, 250% means it accumulated about two-and-a-half cores’ worth of active time during the sample. It does not mean the processor violated arithmetic. On an eight-core chip, Oakley reports that the displayed total can reach 800%.

The arithmetic is internally consistent. The label is the problem.

A core can be active for the whole sample at a low clock frequency or active for the whole sample at a much higher frequency. Activity Monitor calls both 100%. It also gives the same weight to an efficiency core and a performance core despite their different designs.

Oakley’s M4 example makes the distortion satisfyingly blunt. His February 14 test put the same four threads on different core types. He reported:

• Four E-cores at about 1,020 MHz: 99 seconds.
• Four P-cores at nearer 4,000 MHz: 23 seconds.

Same code. A reported 4.3-fold difference in completion time on that particular M4 Pro test. And because Activity Monitor weights an active E-core and an active P-core identically, its percentages give no hint of that gap.

His June 29, 2026 follow-up, “What does Activity Monitor measure?,” used powermetrics as a reference on one Mac mini M4 Pro with 10 P-cores and 4 E-cores running macOS 26.5.1. Oakley reported that a compression workload took about 150 seconds on four E-cores and 8.4 seconds on ten P-cores. Activity Monitor reported 360% for the E cores and a P-to-E CPU% ratio of 3.25 — roughly 1,170% — yet scaling the completed work led him to estimate that the E-core result should have looked closer to 65%, not 360%, if the display represented comparable capability.

Those are measurements from one machine and specific workloads, not conversion factors for every M1–M4 Mac. The useful conclusion is narrower: CPU percentage on Apple silicon is not normalized for core type or frequency.

It is also not energy. A core can remain busy at low frequency and modest power, while a short burst on P-cores completes far more work and draws much more power. Do not read a tall CPU bar as a wattmeter wearing a green hat.

Why macOS leaves the performance cores idle

Apple silicon’s mixed cores are not two interchangeable buckets. macOS uses them to separate work that needs immediate responsiveness from work that can proceed quietly in the background.

The main signal is Quality of Service, or QoS. Apple’s “Prioritize Work at the Task Level” guide describes user-interactive, user-initiated, utility, and background classes. Apple specifically gives indexing, synchronization, and backups as examples of background work.

Apple’s porting documentation also tells developers to use QoS so the system can schedule work on the appropriate type of Apple-silicon core. QoS influences more than CPU priority: Apple says it can affect scheduling, CPU and I/O throughput, and timer latency.

Oakley’s measurements add the core mapping that Activity Monitor leaves unstated. His February 8, 2026 article, “Why E cores make Apple silicon fast,” reports that low-QoS background threads are normally confined to the E-core cluster, while higher-QoS foreground work prefers P-cores and can spill onto E-cores when necessary.

This is scheduling policy, not permanent ownership. A process contains one or more threads. Those threads can have different effective QoS levels, wait for I/O, wake briefly, and migrate between cores. Saying “Safari is on a P-core” is usually an oversimplification. One Safari process may have several threads doing different things in different places over the same second.

The apparently wasteful pattern—E-cores full, P-cores idle—is therefore often deliberate. The background queue may be long, but macOS is preserving the faster cores for the click, scroll, compile, export, or window animation you have not requested yet.

The P-cores are not unemployed. They are on call.

Even monitoring terminology is drifting. Bjango’s iStat Menus 7.3 release notes, dated May 14, 2026, say the app added support for “super cores” and improved CPU core grouping. The public note does not define “super cores” or establish them as an Apple architectural category. Treat labels in third-party tools as presentation choices until the vendor explains exactly what is being grouped.

When busy E-cores are healthy

I start with context, not the height of the graph.

A wall of E-core activity is unsurprising after a restart, a macOS update, a large Photos import, reconnecting a backup disk, changing a large directory tree, or restoring data. These events create work that is real but usually not urgent:

• mds, mds_stores, and mdworker index content for Spotlight.
• photoanalysisd and related Photos services analyze a library.
• backupd performs Time Machine work.
• Security and maintenance services may scan or reconcile changed content.

Oakley reported seeing E-cores busy for the first five to ten minutes after startup on his test Mac, with Spotlight, media-analysis, Time Machine, Siri, and security processes active while the P-cores remained largely available. That duration is his observation, not a deadline your Mac must obey.

The healthy pattern has four parts:

1. The process name fits something that just happened.
2. The foreground remains responsive.
3. Temperatures, fans, and battery behavior are proportionate to the work.
4. The activity declines when the job finishes.

That last part matters most. A snapshot says “busy.” A trend says “finishing” or “stuck.”

If photoanalysisd appeared after importing a large library, read our photoanalysisd explainer before treating it as hostile. If the busy process is kernel_task, the interpretation changes again: high kernel_task can be part of macOS managing thermal pressure, not the original source of the load. Our kernel_task guide covers that trap.

A full E-cluster with an otherwise responsive Mac is not, by itself, evidence of damage, overheating, or a defective chip. It is evidence that the E-cluster is busy. Engineers occasionally have to resist the thrill of promoting a measurement into a diagnosis.

When 100% becomes a real symptom

The bars become interesting when the workload has no plausible end, or when the rest of the machine starts paying for it.

Look harder when several of these are true:

• The same process remains near the top for hours or returns after every restart.
• No import, backup, update, indexing event, or foreground task explains it.
• Search results never appear, backups repeatedly fail, or Photos analysis makes no visible progress.
• The interface stutters, apps take unusually long to open, or audio drops.
• Battery drain, sustained heat, or fan activity continues after the expected work should have ended.
• The process repeatedly exits and relaunches, suggesting a retry loop rather than useful progress.

Apple Community thread 255459515, posted in February 2024, is a useful example precisely because it is not a universal rule. One M1 Pro owner reported two efficiency cores permanently at 100%, severe interface delays, and heavy activity from Time Machine and Spotlight processes. The owner later reported recovering nearly half of the E-core capacity after stopping Time Machine and Spotlight-related work. That describes one machine, its software, and its investigation—not a diagnosis for yours.

In thread 255758583, one M1 Max owner reported E-cores at 80–100% while many P-cores remained lightly used. Again: one configuration, not proof that Apple silicon generally schedules incorrectly.

The right question is not “Are the E-cores at 100%?” It is:

Which process is producing the work, why does that work exist, and is it making progress?

Heat adds another independent signal. CPU percentage alone cannot tell you whether the Mac is thermally stressed because it ignores frequency, core type, GPU activity, and ambient conditions. Our guide to safe MacBook temperatures explains why there is no single magic CPU temperature that separates “fine” from “broken.”

Do not disable indexing, backups, or system daemons merely to make a graph shorter. A quieter graph obtained by preventing useful work is decorative troubleshooting.

How to see where the work is running

Start with Activity Monitor because it is already installed and its limitations are manageable when you know them.

Open the CPU tab, choose View → All Processes, and sort by % CPU. Then choose Window → CPU History. Apple’s Activity Monitor guide confirms that CPU History shows recent processor activity; on Apple silicon, the separate groups reveal whether the E or P cluster is carrying most of the load.

Now correlate the views. If mds_stores is leading the process table and only the E-core group is consistently busy, that is strong circumstantial evidence. It is not a thread-to-core trace. Oakley’s February 14 explainer explicitly notes that Activity Monitor cannot identify which process owns each active core when several processes are competing.

For a closer read, current macOS builds expose asymmetric-multiprocessing and QoS options in powermetrics:

sudo powermetrics \
  --samplers tasks,cpu_power \
  --show-process-amp \
  --show-process-ipc \
  --show-process-qos \
  -i 1000 \
  -n 10

This is a read-only measurement command. It requests ten samples at one-second intervals, shows task data, and adds per-process AMP, instruction/cycle, and QoS information alongside CPU cluster frequency and residency. Output fields vary by macOS release and hardware; run powermetrics --help if an option is unavailable.

powermetrics is deliberately noisy. Read the process rows, then compare them with the E- and P-cluster frequency and residency sections. You are looking for repeated correlation across samples, not one dramatic line.

There is still an honest limit: threads migrate. A ten-second sample can show that a process accumulated work on a cluster; it does not grant that process a permanent desk on Core 3. For exact thread scheduling over time, Xcode Instruments’ CPU Profiler is the deeper tool, but Instruments adds its own measurement load and is excessive for most home diagnosis.

What CoreGuard will—and will not—tell you

This is the part I want monitoring software to handle better: not inventing a red verdict from 100%, but preserving enough context to explain what changed.

CoreGuard is pre-launch. In the Free version, it will show live CPU, GPU, RAM, temperature, and fan readings; name the top app or process in plain English; keep a history of readings; provide threshold alerts and a menu-bar readout; and show every danger warning without a paywall.

That wording is deliberate. Reading history, threshold alerts, and warnings are Free. Pro adds per-app energy detail, the ability to quit a runaway process, and CSV/JSON export of trends and recorded sessions. Pro is a one-time $29 purchase, not a subscription.

CoreGuard will not claim that a full E-core is equivalent to a full P-core. It will not turn a scheduler snapshot into a health score, predict a failure date, or pretend that a background process is dangerous merely because it is busy. It observes and explains; it does not alter macOS scheduling or modify your files.

It also cannot replace Instruments for an exact thread-to-core trace. The useful job here is simpler: name the process, keep enough history to show whether it is settling or recurring, and put CPU activity beside temperature, fans, battery, and system load. One bar is ambiguous. Several independent signals over time are evidence.

The app runs locally and makes zero network connections. It supports macOS 13 or later on Apple silicon and Intel, although the E-core/P-core distinction applies only to Apple silicon. Builds are Developer-ID signed and notarized by Apple.

CoreGuard is not downloadable yet. You can get notified for launch or see the Free and Pro split. Until then, Activity Monitor plus ten honest seconds of powermetrics will already tell you more than staring angrily at the red bars.