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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

63 Cores Blocked by Seven Instructions

480 点作者 nikbackm超过 5 年前

14 条评论

pbsd超过 5 年前
For each input source file, cl.exe creates at least 7 temporary files (with suffixes &quot;gl&quot;, &quot;sy&quot;, &quot;ex&quot;, &quot;in&quot;, &quot;db&quot;, &quot;md&quot;, &quot;lk&quot;). The churn of creating and deleting those, coupled with the slowness of performing checkpointing on a huge empty drive, seem to be the root cause here.<p>This appears somewhat related to this bug report: <a href="https:&#x2F;&#x2F;developercommunity.visualstudio.com&#x2F;content&#x2F;problem&#x2F;310131&#x2F;clexe-creates-so-many-temp-files-it-freezes-the-sy.html" rel="nofollow">https:&#x2F;&#x2F;developercommunity.visualstudio.com&#x2F;content&#x2F;problem&#x2F;...</a><p>Marking the temporary files as FILE_ATTRIBUTE_TEMPORARY could improve things, without having to go into significant Windows kernel changes.
评论 #21313542 未加载
评论 #21312928 未加载
markdog12超过 5 年前
Bruce Dawson does some of Microsoft&#x27;s most valuable work for Windows. Doesn&#x27;t even work for them.
评论 #21315943 未加载
评论 #21311859 未加载
KenanSulayman超过 5 年前
Technically this wasn&#x27;t caused by those instructions but by the spinlocks waiting for the lock to be released. Also &quot;blocked by seven instructions&quot; sounds a bit click-baity.. you can lock the CPU or power off the computer with less than that amount of instructions :-)
评论 #21310432 未加载
评论 #21320174 未加载
评论 #21318363 未加载
评论 #21312418 未加载
vkaku超过 5 年前
It&#x27;s good to see how features turned on by default (System Restore) can have such a bad impact on performance. Thank you for doing the profiling!
评论 #21310862 未加载
评论 #21311116 未加载
strictfp超过 5 年前
So, one busy process performs a file operation that triggers a system restore checkpoint, and the OS locks the entire drive during this file operation? Sounds strange to me.<p>Is the problem that the checkpointing critical section has the same duration as the triggering file operation?<p>I get that there must be some sort of critical section for setting a checkpoint, but I don&#x27;t understand why it takes so long, and why it would be affected by how busy the userspace process that triggered it is.<p>I would expect it to have a short barrier-style critical section; drain all outstanding writes, record some checksum or counter from a kernel data structure, and then release all writers again.<p>In my mind this should be kernel code only, entirely unaffected by userspace, and if designed nicely, quite fast.<p>So I guess I don&#x27;t get what is going on here.
评论 #21320185 未加载
评论 #21318744 未加载
jeffdavis超过 5 年前
It looks like this is a case where a process is holding lock A while waiting on lock B; and every other process is waiting on lock A. That&#x27;s normal enough, though it seems like there are two mistakes:<p>First: Never spin waiting on a lock for 3 seconds. If you expect a lock to be released very quickly, you spin K times and then, if you still don&#x27;t have the lock, try something heavier that can deschedule your process. K should be small enough that your time slice is unlikely to expire while spinning, otherwise, it just causes confusion and wasted work because it looks like your process is doing work when it&#x27;s not.<p>Second: It seems dubious that using a feature like system restore causes all Write calls to wait for a lock held by a process in the middle of I&#x2F;O. I&#x27;m sure there are some cases where that must happen (like if out of buffer space to hold the writes), but I would think it would be harder to hit.<p>EDIT: Rephrased my comment in terms of two problems rather than just the first one.
评论 #21318794 未加载
评论 #21320167 未加载
saagarjha超过 5 年前
Why do the sample counts cluster so heavily on the jne, as opposed to the other instructions in the loop?
评论 #21310406 未加载
评论 #21310749 未加载
alexeiz超过 5 年前
&quot;loop running in the system process while holding a vital NTFS lock&quot;<p>It&#x27;s not about the seven instructions. It&#x27;s the lock that&#x27;s been held while doing a busy loop.
peter_d_sherman超过 5 年前
Excerpt: &quot;...I mean, how often do you have one thread spinning for several seconds in a seven-instruction loop while holding a lock that stops sixty-three other processors from running. That’s just awesome, in a horrible sort of way.&quot;<p>I respectfully disagree.<p>That&#x27;s because everything in the universe that is percieved as negative -- turns out to have a positive use-case somewhere, sometime, in some context...<p>In this case, I think the ability for one core to stop 63 other processor cores is purely awesome, because think of the possible use-cases! Debugger comes to mind immediately, but how about another if let&#x27;s say there are 63 nasty self-resurrecting virus threads running on my PC? What about if you were doing some kind of esoteric OS testing where you needed to return to something like Unix&#x27;s runlevel 1 (single user), but you&#x27;d rather freeze most of the machine (rather than destroying the context of everything else that was previously running?).<p>Oh, here&#x27;s the best one I can think of -- don&#x27;t just do a postmortem, everything&#x27;s dead core dump when something fails -- do a full (frozen!) &quot;live&quot; dump of a system that can be replayed infinitely, from that state!<p>Now, because I take a contradictory position, doesn&#x27;t mean we&#x27;re not friends, or that I don&#x27;t acknowledge your technical brilliance! Your article was absolutely great, and you are absolutely correct that for your use-case, &quot;That’s just awesome, in a horrible sort of way.&quot;.<p>But for my use-cases, it&#x27;s absolutely awsome, in the most awesome sort of way! &lt;g&gt;
评论 #21315526 未加载
评论 #21318029 未加载
评论 #21316401 未加载
snak超过 5 年前
That was a good read. In-depth but understandable. Thanks for sharing.
CawCawCaw超过 5 年前
These posts by Dawson are always interesting. Now, if only he would investigate and remediate the performance deficiencies of other complex systems, such as ... Chrome?
mehrdadn超过 5 年前
Edit: Never mind... I completely missed the word &quot;empty&quot; when reading the critical sentence. :(
评论 #21310419 未加载
Syzygies超过 5 年前
So when did you first realize he was discussing Windows, reading this?<p>The &quot;of course everyone is a straight white male&quot; attitude that the OS need not be stated, so often seen in Windows posts, gave it away for me. However, my biases threw me for way too long: the level of sophistication meant this must be Linux, right? I should have recognized the graphics style in the screen grabs. Certainly not MacOS, but Linux can be all over the map stylistically. Does Windows really still look like that? Wow.
评论 #21329556 未加载
ncmncm超过 5 年前
The cause is obvious: they were building on Microsoft Windows, using the NTFS filesystem. Even Microsoft doesn&#x27;t try to build on NTFS.<p>Changing any single detail gives better results. Use a Samba share from a Linux filesystem. Run Mingw on a Linux system. Run MSVS in Wine on a Linux system.<p>Windows is an execution environment for applications. There is no need for, and no value in, actually performing builds in your target execution environment. Use a system designed from the ground up for builds.
评论 #21313520 未加载
评论 #21313449 未加载
评论 #21311613 未加载