What Does an Idle CPU Do?
duartes.org
duartes.org
I know this because I wrote that 6 (initially 8) micro-instruction loop for the IBM System/370 Model 155-157 in the late '60s. I was told back then that since that model became the most widely sold machine ever I had written the code most executed in the history of computing. :-)
The status latch in the machine that indicated that loop was running was fed to a light on the console and, yep, it was nearly always lit other than when booting the OS.
Were some of the smaller machines (135 or smaller) non-microcode? E.g. RTL or TTL hardwired?
What did that use internally?
FWIW, the transition from the Model 155 to the 157 heralded the introduction of table driven virtual memory. We called it "relocation" hardware then. :-)
The first engineering model of the 155 used core memory but transistor memory became fast, reliable and cheap enough during its development that a very disruptive re-design was performed across the whole family of machines.
That was my first job out of the university and what fun it was! And what an incredible experience working for IBM was then.
I did very little work on the mainframes, lots on the IBM 1800, a process control computer, and my first consulting gig was on a system 32. Don't ask me what programming language it was.
Dunno how true that is today, but I wouldn't be surprised if AIX still uses the same kind of tight event loop internally.
Diagnosing startup problems with all those super quick flashing codes was a nightmare.
Back in the day, I considered doing an open-source knockoff, just to call it SMUT.
Cocke deserved his Turing, no question about it, however I see the intellectual antecedents of RISC being machines like Gordon Bell's PDP-6/10 (with a small, clean, orthogonal instruction set) and Cray's 6600 (with its overlapping execution units). CISC was a doomed effort to make assembly programmers more efficient.
Through the most popular compiler output today is a CISC instruction set, that output is simply run on microprogrammed emulators.
I knew John and it was that work that led him to design an instruction set optimized for compilers that was implemented in the 801. I'm less aware of George's contribution. Perhaps you could enlighten me.
See for example Intel's C6 state. http://www.hardwaresecrets.com/article/Everything-You-Need-t...
Linux 3.9 and higher is immune: it just forcibly disables this feature.
* This didn't work very well until Linux 3.16.
TBH, I have no idea how MONITOR works in a VM. It might be quite messy.
Edit: Here's a really nice explanation: http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/mwait.html
[1]: http://www.freedos.org/wiki/index.php/VirtualBox_-_Chapter_7
I'm only just starting to learn asm so I'm not entirely sure how it works, but the source is available at http://maribu.home.xs4all.nl/zeurkous/download/mirror/dosidl....
I seriously doubt that it is healthy for any computer to run for a longer time with 100% CPU usage.
Computers in the DOS and Win9x days would be at 100% CPU usage for basically as long as they were switched on; and a modern one should be absolutely fine running at 100% for an indefinite amount of time provided that things like the cooling system are in good working condition. The biggest difference between CPUs now and CPUs then is the difference in power consumption between idle/sleep and full power - e.g. a 66MHz 486 consumes <5W at full power (and not much difference when halted) vs. ~5W at idle and close to 100W for a recent Haswell i7.
If I have a DOS guest running for some time in VirtualBox, with full CPU usage, OS X eventually will pop up a nice half transparent window. It tells me that my computer needs now to be shut down and that I should push the power button long enough to do so. It's the Mac version of the BSOD.
That suggests insufficient cooling. If it's a system that's been in use for a while, it's probably time to clean out the heatsinks and fans. If a new system is overheating from 100% CPU usage, then I would consider it defective.
Yes, definitely. The thing to advise is: Clean the heatsinks and fans, and then run a performance test such as prime95 over night to see that the machine indeed can run at 100% usage for a prolonged time. Only then I'd trust a machine that was prone to crashing under load again for my work.
Maybe I missed it, and I did check the earlier post and I understand this is trying to be a simplification, but what was the argument for why I should take the above axiom? Was there one?
Or I am just being too literal and all the author is really trying to say is the current task pointer must always be valid, in Linux. Which is probably true enough (I don't know Linux well) but a much less powerful statement.
From the post contents I suspect the author is using OS as a synonym for Linux.
http://screenshots.en.sftcdn.net/en/scrn/5000/5197/cpu-idle-...
When the idle task is the only task running, it halts the CPU to save power. When the scheduling timer interrupt fires, it wakes up the CPU and calls the scheduler to schedule tasks. If there are other tasks ready to run, the idle task is swapped out to let another task to run but it is still in the ready state. Depending on the scheduling algorithm, the idle task might get picked to run again before other ready tasks. In that case, it should not halt the CPU but rather just busy-loops the rest of the quantum. At that time, the timer interrupt fires and schedules another ready task to run right the way without needing to wake up the CPU.
(/me ducks)
edit: oops, the downvoters are correct; modern cpus have dedicated hardware for that.
Oh, lifts weights, writes a little poetry, works on its side project startup, surfs for cat videos...