466 lines
26 KiB
HTML
466 lines
26 KiB
HTML
<!DOCTYPE html>
|
|
<html>
|
|
<head>
|
|
<meta charset="utf-8">
|
|
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
|
|
<title>CPU Utilization is Wrong</title>
|
|
<meta name="viewport" content="width=device-width">
|
|
<meta name="description" content="CPU Utilization is Wrong">
|
|
<meta name="keywords" content="performance,benchmarking,unixbench,blog">
|
|
|
|
<!-- syntax highlighting CSS -->
|
|
<link rel="stylesheet" href="/blog/css/syntax.css">
|
|
|
|
<!-- Custom CSS -->
|
|
<link rel="stylesheet" href="/blog/css/main.css">
|
|
|
|
<!-- Google tag (gtag.js) -->
|
|
<script async src="https://www.googletagmanager.com/gtag/js?id=G-SYD11KXST1"></script>
|
|
<script>
|
|
window.dataLayer = window.dataLayer || [];
|
|
function gtag(){dataLayer.push(arguments);}
|
|
gtag('js', new Date());
|
|
|
|
gtag('config', 'G-SYD11KXST1');
|
|
</script>
|
|
|
|
</head>
|
|
<body>
|
|
|
|
<div class="page">
|
|
<div class="nav">
|
|
<p class="navhdr">Brendan's site:</p>
|
|
<a href="/overview.html">Start Here</a><br>
|
|
<a href="/index.html">Homepage</a><br>
|
|
<a href="/blog/index.html">Blog</a><br>
|
|
<!-- <a href="/sitemap.html">Full Site Map</a><br> -->
|
|
<a href="/systems-performance-2nd-edition-book.html">Sys Perf book</a><br>
|
|
<a href="/bpf-performance-tools-book.html">BPF Perf book</a><br>
|
|
<a href="/linuxperf.html">Linux Perf</a><br>
|
|
<a href="/ebpf.html">eBPF Tools</a><br>
|
|
<a href="/perf.html">perf Examples</a><br>
|
|
<a href="/methodology.html">Perf Methods</a><br>
|
|
<a href="/usemethod.html">USE Method</a><br>
|
|
<a href="/tsamethod.html">TSA Method</a><br>
|
|
<a href="/offcpuanalysis.html">Off-CPU Analysis</a><br>
|
|
<a href="/activebenchmarking.html">Active Bench.</a><br>
|
|
<a href="/wss.html">WSS Estimation</a><br>
|
|
<a href="/flamegraphs.html">Flame Graphs</a><br>
|
|
<a href="/flamescope.html">Flame Scope</a><br>
|
|
<a href="/heatmaps.html">Heat Maps</a><br>
|
|
<a href="/frequencytrails.html">Frequency Trails</a><br>
|
|
<a href="/colonygraphs.html">Colony Graphs</a><br>
|
|
<a href="/dtrace.html">DTrace Tools</a><br>
|
|
<a href="/dtracetoolkit.html">DTraceToolkit</a><br>
|
|
<a href="/dtkshdemos.html">DtkshDemos</a><br>
|
|
<a href="/guessinggame.html">Guessing Game</a><br>
|
|
<a href="/specials.html">Specials</a><br>
|
|
<a href="/books.html">Books</a><br>
|
|
<a href="/sites.html">Other Sites</a><br>
|
|
|
|
</div>
|
|
|
|
<div class="recent">
|
|
<!-- (this is for the blog) recent books: -->
|
|
<!-- <center><a href="https://informit.com/sale/booksgiving"><img border=0 width=180 src="/Images/booksgiving2021.jpg"></center><br><b>Book sale until Dec 1, 2021: 55% off for 2 or more</b></a><br><br> -->
|
|
<center><a href="/systems-performance-2nd-edition-book.html"><img src="/Images/sysperf2nd_bookcover_360.jpg" width=180></a><br><font size=-2><i><a href="/systems-performance-2nd-edition-book.html">Systems Performance 2nd Ed.</a></i></font></center><br><br>
|
|
|
|
<center><a href="/bpf-performance-tools-book.html"><img src="/Images/bpfperftools_bookcover_360.jpg" width=180></a><br><font size=-2><i><a href="/bpf-performance-tools-book.html">BPF Performance Tools book</a></i></font></center>
|
|
<!--
|
|
<br><center><a href="https://www.portal.reinvent.awsevents.com/connect/search.ww?#loadSearch-searchPhrase=OPN303&searchType=session&tc=0&sortBy=abbreviationSort&p="><img src="/Images/Speaker/reInvent2019_200.jpg" width=180" border=0></a><br><font size=-2><i>I'm speaking at <a href="https://www.portal.reinvent.awsevents.com/connect/search.ww?#loadSearch-searchPhrase=OPN303&searchType=session&tc=0&sortBy=abbreviationSort&p=">AWS re:Invent 2019</a></i></font></center>
|
|
-->
|
|
<br>
|
|
Recent posts:<br>
|
|
<ul style="padding-left:18px">
|
|
|
|
<li>07 Feb 2026 »<br>
|
|
<a href="/blog/2026-02-07/why-i-joined-openai.html">
|
|
Why I joined OpenAI</a></li>
|
|
|
|
<li>05 Dec 2025 »<br>
|
|
<a href="/blog/2025-12-05/leaving-intel.html">
|
|
Leaving Intel</a></li>
|
|
|
|
<li>28 Nov 2025 »<br>
|
|
<a href="/blog/2025-11-28/ai-virtual-brendans.html">
|
|
On "AI Brendans" or "Virtual Brendans"</a></li>
|
|
|
|
<li>22 Nov 2025 »<br>
|
|
<a href="/blog/2025-11-22/intel-is-listening.html">
|
|
Intel is listening, don't waste your shot</a></li>
|
|
|
|
<li>17 Nov 2025 »<br>
|
|
<a href="/blog/2025-11-17/third-stage-engineering.html">
|
|
Third Stage Engineering</a></li>
|
|
|
|
<li>04 Aug 2025 »<br>
|
|
<a href="/blog/2025-08-04/when-to-hire-a-computer-performance-engineering-team-2025-part1.html">
|
|
When to Hire a Computer Performance Engineering Team (2025) part 1 of 2</a></li>
|
|
|
|
<li>22 May 2025 »<br>
|
|
<a href="/blog/2025-05-22/3-years-of-extremely-remote-work.html">
|
|
3 Years of Extremely Remote Work</a></li>
|
|
|
|
<li>01 May 2025 »<br>
|
|
<a href="/blog/2025-05-01/doom-gpu-flame-graphs.html">
|
|
Doom GPU Flame Graphs</a></li>
|
|
|
|
<li>29 Oct 2024 »<br>
|
|
<a href="/blog/2024-10-29/ai-flame-graphs.html">
|
|
AI Flame Graphs</a></li>
|
|
|
|
<li>22 Jul 2024 »<br>
|
|
<a href="/blog/2024-07-22/no-more-blue-fridays.html">
|
|
No More Blue Fridays</a></li>
|
|
|
|
<li>24 Mar 2024 »<br>
|
|
<a href="/blog/2024-03-24/linux-crisis-tools.html">
|
|
Linux Crisis Tools</a></li>
|
|
|
|
<li>17 Mar 2024 »<br>
|
|
<a href="/blog/2024-03-17/the-return-of-the-frame-pointers.html">
|
|
The Return of the Frame Pointers</a></li>
|
|
|
|
<li>10 Mar 2024 »<br>
|
|
<a href="/blog/2024-03-10/ebpf-documentary.html">
|
|
eBPF Documentary</a></li>
|
|
|
|
<li>28 Apr 2023 »<br>
|
|
<a href="/blog/2023-04-28/ebpf-security-issues.html">
|
|
eBPF Observability Tools Are Not Security Tools</a></li>
|
|
|
|
<li>01 Mar 2023 »<br>
|
|
<a href="/blog/2023-03-01/computer-performance-future-2022.html">
|
|
USENIX SREcon APAC 2022: Computing Performance: What's on the Horizon</a></li>
|
|
|
|
<li>17 Feb 2023 »<br>
|
|
<a href="/blog/2023-02-17/srecon-apac-2023.html">
|
|
USENIX SREcon APAC 2023: CFP</a></li>
|
|
|
|
<li>02 May 2022 »<br>
|
|
<a href="/blog/2022-05-02/brendan-at-intel.html">
|
|
Brendan@Intel.com</a></li>
|
|
|
|
<li>15 Apr 2022 »<br>
|
|
<a href="/blog/2022-04-15/netflix-farewell-1.html">
|
|
Netflix End of Series 1</a></li>
|
|
|
|
<li>09 Apr 2022 »<br>
|
|
<a href="/blog/2022-04-09/tensorflow-library-performance.html">
|
|
TensorFlow Library Performance</a></li>
|
|
|
|
<li>19 Mar 2022 »<br>
|
|
<a href="/blog/2022-03-19/why-dont-you-use.html">
|
|
Why Don't You Use ...</a></li>
|
|
|
|
</ul>
|
|
<a href="/blog/index.html">Blog index</a><br>
|
|
<a href="/blog/about.html">About</a><br>
|
|
<a href="/blog/rss.xml">RSS</a><br>
|
|
<!--
|
|
<br><center><a href="https://www.usenix.org/conference/lisa18"><img src="https://www.usenix.org/sites/default/files/lisa18_banner_join-me.png" width=180></a><br><font size=-2><i>I am program co-chair for LISA 2018</i></font></center>
|
|
-->
|
|
</div>
|
|
|
|
<div class="site">
|
|
<div class="header">
|
|
<h1 class="title"><a href="/blog/index.html">Brendan Gregg's Blog</a></h1>
|
|
<a class="extra" href="/blog/index.html">home</a>
|
|
</div>
|
|
|
|
<h2 class="big">CPU Utilization is Wrong</h2>
|
|
<p class="meta">09 May 2017</p>
|
|
|
|
<div class="post">
|
|
<p>The metric we all use for CPU utilization is deeply misleading, and getting worse every year. What is CPU utilization? How busy your processors are? No, that's not what it measures. Yes, I'm talking about the "%CPU" metric used <em>everywhere</em>, by <em>everyone</em>. In every performance monitoring product. In top(1).</p>
|
|
|
|
<p>What you may think 90% CPU utilization means:</p>
|
|
|
|
<p><center><a href="/blog/images/2017/cpubusyidle.png"><img src="/blog/images/2017/cpubusyidle.png" width=700 border=0></a></center></p>
|
|
|
|
<p>What it might really mean:</p>
|
|
|
|
<p><center><a href="/blog/images/2017/cpubusystalledidle.png"><img src="/blog/images/2017/cpubusystalledidle.png" width=700 border=0></a></center></p>
|
|
|
|
<p>Stalled means the processor was not making forward progress with instructions, and usually happens because it is waiting on memory I/O.
|
|
The ratio I drew above (between busy and stalled) is what I typically see in production. Chances are, you're mostly stalled, but don't know it.</p>
|
|
|
|
<p>What does this mean for you? Understanding how much your CPUs are stalled can direct performance tuning efforts between reducing code or reducing memory I/O.
|
|
Anyone looking at CPU performance, especially on clouds that auto scale based on CPU, would benefit from knowing the stalled component of their %CPU.</p>
|
|
|
|
<h2>What really is CPU Utilization?</h2>
|
|
|
|
<p>The metric we call CPU utilization is really "non-idle time": the time the CPU was not running the idle thread. Your operating system kernel (whatever it is) usually tracks this during context switch. If a non-idle thread begins running, then stops 100 milliseconds later, the kernel considers that CPU utilized that entire time.</p>
|
|
|
|
<p>This metric is as old as time sharing systems. The Apollo Lunar Module guidance computer (a pioneering time sharing system) called its idle thread the "DUMMY JOB", and engineers tracked cycles running it vs real tasks as a important computer utilization metric. (I wrote about this <a href="http://www.brendangregg.com/usemethod.html#Apollo">before</a>.)</p>
|
|
|
|
<p>So what's wrong with this?</p>
|
|
|
|
<p>Nowadays, CPUs have become much faster than main memory, and waiting on memory dominates what is still called "CPU utilization". When you see high %CPU in top(1), you might think of the processor as being the bottleneck – the CPU package under the heat sink and fan – when it's really those banks of DRAM.</p>
|
|
|
|
<p>This has been getting worse. For a long time processor manufacturers were scaling their clockspeed quicker than DRAM was scaling its access latency (the "CPU DRAM gap"). That levelled out around 2005 with 3 GHz processors, and since then processors have scaled using more cores and hyperthreads, plus multi-socket configurations, all putting more demand on the memory subsystem. Processor manufacturers have tried to reduce this memory bottleneck with larger and smarter CPU caches, and faster memory busses and interconnects. But we're still usually stalled.</p>
|
|
|
|
<!--
|
|
You might be wondering: can't the kernel context switch out a thread that is memory stalled so that it can run something else? No. That takes way too long (microseconds, instead of nanoseconds), plus, the kernel has no way to pause a thread mid-instruction (Intel, that's not a feature request). What modern CPUs can do, is "switch" out stalled instructions and run other *hyperthreads* to reclaim those cycles (yes, I'm simplifying, what really happens is micro-ops, but if I tried to explain it all this would become a book). Hyperthreads help, but the typical ratio I drew above is already after their help.
|
|
-->
|
|
|
|
<h2>How to tell what the CPUs are really doing</h2>
|
|
|
|
<p>By using Performance Monitoring Counters (PMCs): hardware counters that can be read using <a href="/perf.html">Linux perf</a>, and other tools. For example, measuring the entire system for 10 seconds:</p>
|
|
|
|
<pre>
|
|
# <b>perf stat -a -- sleep 10</b>
|
|
|
|
Performance counter stats for 'system wide':
|
|
|
|
641398.723351 task-clock (msec) # 64.116 CPUs utilized (100.00%)
|
|
379,651 context-switches # 0.592 K/sec (100.00%)
|
|
51,546 cpu-migrations # 0.080 K/sec (100.00%)
|
|
13,423,039 page-faults # 0.021 M/sec
|
|
1,433,972,173,374 cycles # 2.236 GHz (75.02%)
|
|
<not supported> stalled-cycles-frontend
|
|
<not supported> stalled-cycles-backend
|
|
1,118,336,816,068 instructions # <b>0.78 insns per cycle</b> (75.01%)
|
|
249,644,142,804 branches # 389.218 M/sec (75.01%)
|
|
7,791,449,769 branch-misses # 3.12% of all branches (75.01%)
|
|
|
|
10.003794539 seconds time elapsed
|
|
</pre>
|
|
|
|
<p>The key metric here is <strong>instructions per cycle</strong> (<tt>insns per cycle</tt>: IPC), which shows on average how many instructions we were completed for each CPU clock cycle. The higher, the better (a simplification). The above example of 0.78 sounds not bad (78% busy?) until you realize that this processor's top speed is an IPC of 4.0. This is also known as <em>4-wide</em>, referring to the instruction fetch/decode path. Which means, the CPU can retire (complete) four instructions with every clock cycle. So an IPC of 0.78 on a 4-wide system, means the CPUs are running at 19.5% their top speed. Newer Intel processors may move to 5-wide.</p>
|
|
|
|
<p>There are hundreds more PMCs you can use to dig further: measuring stalled cycles directly by different types.</p>
|
|
|
|
<h3>In the cloud</h3>
|
|
|
|
<p>If you are in a virtual environment, you might not have access to PMCs, depending on whether the hypervisor supports them for guests. I recently posted about <a href="/blog/2017-05-04/the-pmcs-of-ec2.html">The PMCs of EC2: Measuring IPC</a>, showing how PMCs are now available for dedicated host types on the AWS EC2 Xen-based cloud.</p>
|
|
|
|
<h2>Interpretation and actionable items</h2>
|
|
|
|
<p>If your <strong>IPC is < 1.0</strong>, you are likely memory stalled, and software tuning strategies include reducing memory I/O, and improving CPU caching and memory locality, especially on NUMA systems. Hardware tuning includes using processors with larger CPU caches, and faster memory, busses, and interconnects.</p>
|
|
|
|
<p>If your <strong>IPC is > 1.0</strong>, you are likely instruction bound. Look for ways to reduce code execution: eliminate unnecessary work, cache operations, etc. <a href="http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html">CPU flame graphs</a> are a great tool for this investigation. For hardware tuning, try a faster clock rate, and more cores/hyperthreads.</p>
|
|
|
|
<p>For my above rules, I split on an IPC of 1.0. Where did I get that from? I made it up, based on my prior work with PMCs. Here's how you can get a value that's custom for your system and runtime: write two dummy workloads, one that is CPU bound, and one memory bound. Measure their IPC, then calculate their mid point.</p>
|
|
|
|
<h2>What performance monitoring products should tell you</h2>
|
|
|
|
<p>Every performance tool should show IPC along with %CPU. Or break down %CPU into instruction-retired cycles vs stalled cycles, eg, %INS and %STL.</p>
|
|
|
|
<p>As for top(1), there is tiptop(1) for Linux, which shows IPC by process:</p>
|
|
|
|
<pre>
|
|
tiptop - [root]
|
|
Tasks: 96 total, 3 displayed screen 0: default
|
|
|
|
<b>PID</b> [ %CPU] %SYS P Mcycle Minstr <b>IPC</b> %MISS %BMIS %BUS <b>COMMAND</b>
|
|
<b>3897</b> 35.3 28.5 4 274.06 178.23 <b>0.65</b> 0.06 0.00 0.0 <b>java</b>
|
|
<b>1319+</b> 5.5 2.6 6 87.32 125.55 <b>1.44</b> 0.34 0.26 0.0 <b>nm-applet</b>
|
|
<b>900</b> 0.9 0.0 6 25.91 55.55 <b>2.14</b> 0.12 0.21 0.0 <b>dbus-daemo</b>
|
|
</pre>
|
|
|
|
<h2>Other reasons CPU utilization is misleading</h2>
|
|
|
|
<p>It's not just memory stall cycles that makes CPU utilization misleading. Other factors include:</p>
|
|
|
|
<ul>
|
|
<li>Temperature trips stalling the processor.</li>
|
|
<li>Turboboost varying the clockrate.</li>
|
|
<li>The kernel varying the clock rate with speed step.</li>
|
|
<li>The problem with averages: 80% utilized over 1 minute, hiding bursts of 100%.</li>
|
|
<li>Spin locks: the CPU is utilized, and has high IPC, but the app is not making logical forward progress.</li>
|
|
</ul>
|
|
|
|
<h2>Update: is CPU utilization actually wrong?</h2>
|
|
|
|
<p>There have been hundreds of comments on this post, here (below) and elsewhere (<a href="https://news.ycombinator.com/item?id=14301739">1</a>, <a href="https://www.reddit.com/r/programming/comments/6a6v8g/cpu_utilization_is_wrong/">2</a>). Thanks to everyone for taking the time and the interest in this topic. To summarize my responses: I'm not talking about iowait at all (that's disk I/O), and there are actionable items if you know you are memory bound (see above).</p>
|
|
|
|
<p>But is CPU utilization actually wrong, or just deeply misleading? I think many people interpret high %CPU to mean that the processing unit is the bottleneck, which is wrong (as I said earlier). At that point you don't yet know, and it is often something external. Is the metric technically correct? If the CPU stall cycles can't be used by anything else, aren't they are therefore "utilized waiting" (which sounds like an oxymoron)? In some cases, yes, you could say that %CPU as an OS-level metric is technically correct, but deeply misleading. With hyperthreads, however, those stalled cycles can now be used by another thread, so %CPU may count cycles as utilized that are in fact available. That's wrong. In this post I wanted to focus on the interpretation problem and suggested solutions, but yes, there are technical problems with this metric as well.</p>
|
|
|
|
<p>You might just say that utilization as a metric was already broken, as Adrian Cockcroft discussed <a href="http://www.hpts.ws/papers/2007/Cockcroft_HPTS-Useless.pdf">previously</a>.</p>
|
|
|
|
<h2>Conclusion</h2>
|
|
|
|
<p>CPU utilization has become a deeply misleading metric: it includes cycles waiting on main memory, which can dominate modern workloads. Perhaps %CPU should be renamed to %CYC, short for cycles. You can figure out what %CPU really means by using additional metrics, including instructions per cycle (IPC). An IPC < 1.0 likely means memory bound, and an IPC > 1.0 likely means instruction bound. I covered IPC in my <a href="/blog/2017-05-04/the-pmcs-of-ec2.html">previous post</a>, including an introduction to the Performance Monitoring Counters (PMCs) needed to measure it.</p>
|
|
|
|
<p>Performance monitoring products that show %CPU – which is all of them – should also show PMC metrics to explain what that means, and not mislead the end user. For example, they can show %CPU with IPC, and/or instruction-retired cycles vs stalled cycles. Armed with these metrics, developers and operators can choose how to better tune their applications and systems.</p>
|
|
|
|
<!--
|
|
And BTW, the companies that make these products are unlikely to add IPC on their own: in my experience, they are *coin-operated*, and only add features when enough paying customers ask for it. So go ask for it.
|
|
-->
|
|
|
|
</div>
|
|
|
|
|
|
|
|
<br><hr>
|
|
<script type="text/javascript">
|
|
var disqus_shortname = 'brendangregg';
|
|
|
|
function loadshowdisqus(id) {
|
|
// from disqus:
|
|
var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;
|
|
dsq.src = '//' + disqus_shortname + '.disqus.com/embed.js';
|
|
(document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);
|
|
// mine:
|
|
var c = document.getElementById(id); c.style.display = (c.style.display == "none" ? "block" : "none");
|
|
}
|
|
</script>
|
|
<div id="comments_button" onclick='loadshowdisqus("comments_content")'><p style="color:blue"><u>Click here for Disqus comments (ad supported).</u></p></div>
|
|
<div id="comments_content" style="display:none">
|
|
<p><font size=-1><i>You are welcome to comment here, but I've been meaning to switch comment systems one day and I don't know yet if I can preserve existing comments (I'll try to find a way).</i></font></p>
|
|
<div id="disqus_thread"></div>
|
|
<noscript>Please enable JavaScript to view the <a href="http://disqus.com/?ref_noscript">comments powered by Disqus.</a></noscript>
|
|
<a href="http://disqus.com" class="dsq-brlink">comments powered by <span class="logo-disqus">Disqus</span></a>
|
|
</div>
|
|
|
|
|
|
<div class="recentmobile">
|
|
<hr><center>Site Navigation</center><br>
|
|
<!-- (this is for /index.html etc) recent books: -->
|
|
<!-- <center><a href="https://informit.com/sale/booksgiving"><img border=0 width=180 src="/Images/booksgiving2021.jpg"></center><br><b>Book sale until Dec 1, 2021: 55% off for 2 or more</b></a><br><br> -->
|
|
<center><a href="/systems-performance-2nd-edition-book.html"><img src="/Images/sysperf2nd_bookcover_360.jpg" width=180></a><br><font size=-2><i><a href="/systems-performance-2nd-edition-book.html">Systems Performance 2nd Ed.</a></i></font></center><br><br>
|
|
|
|
<center><a href="/bpf-performance-tools-book.html"><img src="/Images/bpfperftools_bookcover_360.jpg" width=180></a><br><font size=-2><i><a href="/bpf-performance-tools-book.html">BPF Performance Tools book</a></i></font></center>
|
|
<!--
|
|
<br><center><a href="https://www.portal.reinvent.awsevents.com/connect/search.ww?#loadSearch-searchPhrase=OPN303&searchType=session&tc=0&sortBy=abbreviationSort&p="><img src="/Images/Speaker/reInvent2019_200.jpg" width=180" border=0></a><br><font size=-2><i>I'm speaking at <a href="https://www.portal.reinvent.awsevents.com/connect/search.ww?#loadSearch-searchPhrase=OPN303&searchType=session&tc=0&sortBy=abbreviationSort&p=">AWS re:Invent 2019</a></i></font></center>
|
|
-->
|
|
<br>
|
|
|
|
Recent posts:<br>
|
|
<ul style="padding-left:18px">
|
|
|
|
<li class="recent">07 Feb 2026 »<br>
|
|
<a href="/blog/2026-02-07/why-i-joined-openai.html">
|
|
Why I joined OpenAI</a></li>
|
|
|
|
<li class="recent">05 Dec 2025 »<br>
|
|
<a href="/blog/2025-12-05/leaving-intel.html">
|
|
Leaving Intel</a></li>
|
|
|
|
<li class="recent">28 Nov 2025 »<br>
|
|
<a href="/blog/2025-11-28/ai-virtual-brendans.html">
|
|
On "AI Brendans" or "Virtual Brendans"</a></li>
|
|
|
|
<li class="recent">22 Nov 2025 »<br>
|
|
<a href="/blog/2025-11-22/intel-is-listening.html">
|
|
Intel is listening, don't waste your shot</a></li>
|
|
|
|
<li class="recent">17 Nov 2025 »<br>
|
|
<a href="/blog/2025-11-17/third-stage-engineering.html">
|
|
Third Stage Engineering</a></li>
|
|
|
|
<li class="recent">04 Aug 2025 »<br>
|
|
<a href="/blog/2025-08-04/when-to-hire-a-computer-performance-engineering-team-2025-part1.html">
|
|
When to Hire a Computer Performance Engineering Team (2025) part 1 of 2</a></li>
|
|
|
|
<li class="recent">22 May 2025 »<br>
|
|
<a href="/blog/2025-05-22/3-years-of-extremely-remote-work.html">
|
|
3 Years of Extremely Remote Work</a></li>
|
|
|
|
<li class="recent">01 May 2025 »<br>
|
|
<a href="/blog/2025-05-01/doom-gpu-flame-graphs.html">
|
|
Doom GPU Flame Graphs</a></li>
|
|
|
|
<li class="recent">29 Oct 2024 »<br>
|
|
<a href="/blog/2024-10-29/ai-flame-graphs.html">
|
|
AI Flame Graphs</a></li>
|
|
|
|
<li class="recent">22 Jul 2024 »<br>
|
|
<a href="/blog/2024-07-22/no-more-blue-fridays.html">
|
|
No More Blue Fridays</a></li>
|
|
|
|
<li class="recent">24 Mar 2024 »<br>
|
|
<a href="/blog/2024-03-24/linux-crisis-tools.html">
|
|
Linux Crisis Tools</a></li>
|
|
|
|
<li class="recent">17 Mar 2024 »<br>
|
|
<a href="/blog/2024-03-17/the-return-of-the-frame-pointers.html">
|
|
The Return of the Frame Pointers</a></li>
|
|
|
|
<li class="recent">10 Mar 2024 »<br>
|
|
<a href="/blog/2024-03-10/ebpf-documentary.html">
|
|
eBPF Documentary</a></li>
|
|
|
|
<li class="recent">28 Apr 2023 »<br>
|
|
<a href="/blog/2023-04-28/ebpf-security-issues.html">
|
|
eBPF Observability Tools Are Not Security Tools</a></li>
|
|
|
|
<li class="recent">01 Mar 2023 »<br>
|
|
<a href="/blog/2023-03-01/computer-performance-future-2022.html">
|
|
USENIX SREcon APAC 2022: Computing Performance: What's on the Horizon</a></li>
|
|
|
|
<li class="recent">17 Feb 2023 »<br>
|
|
<a href="/blog/2023-02-17/srecon-apac-2023.html">
|
|
USENIX SREcon APAC 2023: CFP</a></li>
|
|
|
|
<li class="recent">02 May 2022 »<br>
|
|
<a href="/blog/2022-05-02/brendan-at-intel.html">
|
|
Brendan@Intel.com</a></li>
|
|
|
|
<li class="recent">15 Apr 2022 »<br>
|
|
<a href="/blog/2022-04-15/netflix-farewell-1.html">
|
|
Netflix End of Series 1</a></li>
|
|
|
|
<li class="recent">09 Apr 2022 »<br>
|
|
<a href="/blog/2022-04-09/tensorflow-library-performance.html">
|
|
TensorFlow Library Performance</a></li>
|
|
|
|
<li class="recent">19 Mar 2022 »<br>
|
|
<a href="/blog/2022-03-19/why-dont-you-use.html">
|
|
Why Don't You Use ...</a></li>
|
|
|
|
</ul>
|
|
<a href="/blog/index.html">Blog index</a><br>
|
|
<a href="/blog/about.html">About</a><br>
|
|
<a href="/blog/rss.xml">RSS</a><br>
|
|
<!-- also edit _layouts/default.html -->
|
|
<!--
|
|
<br><a href="https://www.usenix.org/conference/lisa18"><img src="https://www.usenix.org/sites/default/files/lisa18_banner_join-me.png" width=180></a><br><font size=-2><i>I am program co-chair for LISA 2018</i></font>
|
|
-->
|
|
|
|
<hr>
|
|
</div>
|
|
<div class="navmobile">
|
|
<p class="navhdr">Brendan's site:</p>
|
|
<a href="/overview.html">Start Here</a><br>
|
|
<a href="/index.html">Homepage</a><br>
|
|
<a href="/blog/index.html">Blog</a><br>
|
|
<!-- <a href="/sitemap.html">Full Site Map</a><br> -->
|
|
<a href="/systems-performance-2nd-edition-book.html">Sys Perf book</a><br>
|
|
<a href="/bpf-performance-tools-book.html">BPF Perf book</a><br>
|
|
<a href="/linuxperf.html">Linux Perf</a><br>
|
|
<a href="/ebpf.html">eBPF Tools</a><br>
|
|
<a href="/perf.html">perf Examples</a><br>
|
|
<a href="/methodology.html">Perf Methods</a><br>
|
|
<a href="/usemethod.html">USE Method</a><br>
|
|
<a href="/tsamethod.html">TSA Method</a><br>
|
|
<a href="/offcpuanalysis.html">Off-CPU Analysis</a><br>
|
|
<a href="/activebenchmarking.html">Active Bench.</a><br>
|
|
<a href="/wss.html">WSS Estimation</a><br>
|
|
<a href="/flamegraphs.html">Flame Graphs</a><br>
|
|
<a href="/flamescope.html">Flame Scope</a><br>
|
|
<a href="/heatmaps.html">Heat Maps</a><br>
|
|
<a href="/frequencytrails.html">Frequency Trails</a><br>
|
|
<a href="/colonygraphs.html">Colony Graphs</a><br>
|
|
<a href="/dtrace.html">DTrace Tools</a><br>
|
|
<a href="/dtracetoolkit.html">DTraceToolkit</a><br>
|
|
<a href="/dtkshdemos.html">DtkshDemos</a><br>
|
|
<a href="/guessinggame.html">Guessing Game</a><br>
|
|
<a href="/specials.html">Specials</a><br>
|
|
<a href="/books.html">Books</a><br>
|
|
<a href="/sites.html">Other Sites</a><br>
|
|
|
|
</div>
|
|
|
|
<div class="footer">
|
|
<div class="contact">
|
|
Copyright 2025 Brendan Gregg.<br><a href="/blog/about.html">About this blog</a>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
</body>
|
|
</html>
|