TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Why is my CPU usage always 100%?

537 点作者 pncnmnp4 个月前

22 条评论

WediBlino4 个月前
An old manager of mine once spent the day trying to kill a process that was running at 99% on Windows box.<p>When I finally got round to see what he was doing I was disappointed to find he was attempting to kill the &#x27;system idle&#x27; process.
评论 #42685227 未加载
评论 #42682856 未加载
评论 #42682841 未加载
评论 #42685953 未加载
评论 #42686936 未加载
评论 #42689627 未加载
评论 #42682677 未加载
评论 #42687956 未加载
评论 #42689706 未加载
评论 #42682931 未加载
评论 #42686896 未加载
评论 #42682673 未加载
veltas4 个月前
It doesn&#x27;t feel like reading 4 times is necessarily a portable solution, if there will be more versions at different speeds and different I&#x2F;O architectures; or how this will work under more load, and whether the original change was done to fix some other performance problem OP is not aware of, but not sure what else can be done. Unfortunately many vendors like Marvell can seriously under-document crucial features like this. If anything it would be good to put some of this info in the comment itself, not very elegant but how else practically are we meant to keep track of this, is the mailing list part of the documentation?<p>Doesn&#x27;t look like there&#x27;s a lot of discussion on the mailing list, but I don&#x27;t know if I&#x27;m reading the thread view correctly.
评论 #42682624 未加载
评论 #42682836 未加载
评论 #42681269 未加载
rbanffy4 个月前
In the late 1990&#x27;s I worked in a company that had a couple mainframes in their fleet and once I looked into a resource usage screen (Omegamon, perhaps? Is it that old?) and noticed the CPU was pegged at 100%. I asked the operator if that was normal. His answer was &quot;Of course. We paid for that CPU, might as well use it&quot;. Funny though that mainframes are designed for that - most, if not all, non-application work is offloaded to other processors in the system so that the CPU can run applications as fast as it can.
评论 #42682437 未加载
sneela4 个月前
This is a wonderful write-up and a very enjoyable read. Although my knowledge about systems programming on ARM is limited, I know that it isn&#x27;t easy to read hardware-based time counters; at the very least, it&#x27;s not as simple as the x86 rdtsc [1]. This is probably why the author writes:<p>&gt; This code is more complicated than what I expected to see. I was thinking it would just be a simple register read. Instead, it has to write a 1 to the register, and then delay for a while, and then read back the same register. There was also a very noticeable FIXME in the comment for the function, which definitely raised a red flag in my mind.<p>Regardless, this was a very nice read and I&#x27;m glad they got down to the issue and the problem fixed.<p>[1]: <a href="https:&#x2F;&#x2F;www.felixcloutier.com&#x2F;x86&#x2F;rdtsc" rel="nofollow">https:&#x2F;&#x2F;www.felixcloutier.com&#x2F;x86&#x2F;rdtsc</a>.
评论 #42681988 未加载
dmitrygr4 个月前
Curiously, instead of &quot;set capture reg, wait for clock edge, read&quot;, the &quot;read reg twice, until same result is obtained&quot; approach is ignored. This is strange as it is usually much faster - reading a 3.25MHz counter at 200MHz+ twice is very likely to see the same value twice. For a 32KHz counter, it is basically guaranteed.<p><pre><code> u32 val; do { val = readl(...); } while (val != readl(...)); return val; </code></pre> compiles to a nice 6-instr little function on arm&#x2F;thumb too, with no delays<p><pre><code> readclock: LDR R2, =... 1: LDR R0, [R2] LDR R1, [R2] CMP R0, R1 BNE 1b BX LR</code></pre>
askvictor4 个月前
My recurring issue (on a variety of laptops, both Linux and Windows): the fans will start going full-blast, everything slows down, then as soon as I open a task manager CPU usage drops from 100% to something negligible.
评论 #42688874 未加载
steventhedev4 个月前
Aside from the technical beauty of this post, what is the practical impact of this?<p>Fan speeds should ideally be looking at temperature sensors, CPU idling is working albeit with interrupt waits as pointed out here. The only impact seems to be surprise that the CPU is working harder than it really is when looking at this number.<p>It&#x27;s far better to look at the system load (which was 0.0 - already a strong hint this system is working below capacity). It has a formal definition (average waiting cpu task queue depth over 1, 5, 10 minutes) and succinctly captures the concept of &quot;this machine is <i>under load</i>&quot;.<p>Many years ago, a coworker deployed a bad auditd config. CPU usage was below 10%, but system load was 20x the number of cores. We moved all our alerts to system load and used that instead.
thrdbndndn4 个月前
I don&#x27;t get the fix.<p>Why reading it multiple times will fix the issue?<p>Is it just because reading takes time, therefore reading multiple time makes the needed time from writing to reading passes? If so, it sounds like a worse solution than just extending waiting delay longer like the author did initially.<p>If not, then I would like to know the reason.<p>(Needless to say, a great article!)
评论 #42682719 未加载
评论 #42684209 未加载
评论 #42682202 未加载
评论 #42689652 未加载
评论 #42682397 未加载
evanjrowley4 个月前
This headline reminded me of Mumptris, an implementation of Tetris in the old mainframe-oriented language MUMPS, which by design, uses 100% CPU to reduce latency: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=4085593">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=4085593</a>
a1o4 个月前
This was very well written, I somehow read every single line and didn&#x27;t skip to the end. Great work too!
RajT884 个月前
TIL there are still Chumby&#x27;s alive in the wild. My Insignia Chumby 8 didn&#x27;t last.
rbohac4 个月前
This was a well written article! It was nice to read the process of troubleshooting with the rabbit holes included. Glad you stuck it out!
WalterBright4 个月前
I noticed that one time. Looked at the process list, and what was running was a program that enabled streaming. But since I wasn&#x27;t streaming anything, I wondered what it was doing reading the disk drive.<p>So I uninstalled it.<p>Not having any programs that are not good citizens.
ndesaulniers4 个月前
Great read! Eerily similar to some bugs I&#x27;ve had, but the root cause has been a compiler bug. Debugging a kernel that doesn&#x27;t boot is... interesting. QEMU+GDB to the rescue.
NotYourLawyer4 个月前
That’s an awful lot of effort to deal with an issue that was basically just cosmetic. I suspect at some point the author was just nerd sniped though.
评论 #42687940 未加载
g-b-r4 个月前
I expected it to be about holding down the spacebar :&#x2F;
评论 #42681543 未加载
评论 #42681438 未加载
评论 #42686790 未加载
amelius4 个月前
To diagnose, why not run &quot;time top&quot; and look at the user and sys outputs?
markhahn4 个月前
very nice investigation.<p>shame about the unnecessary use of cat :)
评论 #42693991 未加载
InsomniacL4 个月前
&gt; Chumby’s kernel did a total of 5 reads of the CVWR register. The other two kernels did a total of 3 reads.<p>&gt; I opted to use 4 as a middle ground<p>reminded me of xkcd: Standards<p><a href="https:&#x2F;&#x2F;xkcd.com&#x2F;927&#x2F;" rel="nofollow">https:&#x2F;&#x2F;xkcd.com&#x2F;927&#x2F;</a>
TrickyReturn4 个月前
Probably running Slack...
Suppafly4 个月前
Isn&#x27;t this one of those problems that switching to linux is supposed to fix?
评论 #42684696 未加载
begueradj4 个月前
Oops, this is not valid.
评论 #42681297 未加载
评论 #42681259 未加载
评论 #42681316 未加载
评论 #42681253 未加载
评论 #42681200 未加载
评论 #42681340 未加载