Unfortunate typo: the article says "Having placed the fresnel lens, we're not able to get an usable image on the whole 40x30cm sensor." but I think the "not" should be "now". Having "not" reverse the meaning of the critical sentence!
It's easy to make these 800V systems totally safe. You just have to combine this idea with the extremely sensible plan to put data centers in space and then there will be no worry about when "someone pulls out a rackmount unit" because there not be someone within hundreds of kilometers.
I think that is correct, but yes, a delay-slot instruction that is always executed is easy to reason about. Speculative execution that gets real? shudder
It did not help that the performance of the Xbox 360 CPU (and Cell) was terrible. In-order execution without the crazy-high frequencies the CPU was designed for was a failure.
Author here: This is not a common problem. I think I was told that Alpha had basically the same bug but it is a bug, for sure. Speculative execution causing problematic side effects is a deal killer.
Speculative execution, however, can cause less problematic side effects. For instance, a speculatively executed load or prefetch will usually actually prefetch which will pollute the cache, TLB, etc., and reveal side-band information, but that is a performance problem and perhaps a subtle security flaw, not a correctness bug like this was.
The foreground process will only get scheduled ahead of the background process if there is a shortage of CPU power. On today's many-core consumer machines it is much more likely that the background process will continue to make progress, with the only thing slowing it down being the repeated page faults.
Counting on CPU starvation to save memory seems like a very fragile solution.
I agree that commit peaks can affect foreground performance. I've filed bugs for an ephemeral 480 MiB bug in Chrome (caused by an errant product image), and I blogged about an errant 4 GiB allocation that wiped out the disk cache on my 8 GiB machine (https://randomascii.wordpress.com/2012/09/04/windows-slowdow...).
But treating working-set peaks as synonymous with commit peaks is problematic. I still believe that trimming of working sets will rarely save memory, and a working-set cap will virtually never be better than occasional trimming. The cap fails to address the higher-than-the-cap memory consumption in many cases, it just makes it more expensive.
My test program already proves that if you alloc-and-dirty memory aggressively then in background mode you will consume much more CPU time. If your metric is "interfering with foreground processes" then this is fine, but I think the slowdown is severe enough to matter.
As for saving memory, I see your point, but I still don't see how the cap would be better than per-second trimming. If the clean-then-zeroed page is not touched again by the background process then either method would make it available. If the clean-then-zeroed page is touched again by the background process then the whole process of removing it from the working set, zeroing it, then reading it back in and faulting back in is a waste of time. So, again, I'm struggling to find a scenario where the cap is more effective than once-per-second trimming.
That all makes sense (although I think this feature appeared in Windows 7 rather than XP), and I certainly understand the value of a background mode.
But does the working-set cap _work_? In that scenario where you've got heavy memory pressure I still think it doesn't.
If the background process is typically touching less than 32 MiB in a second then a per-second trimming could reduce the working-set effectively.
If the background process is typically touching more than 32 MiB in a second then the fault-time trimming doesn't work because while it trims the memory from the working set, there is no time for the memory to be paged out, and if the memory did get paged out it would make it even worse because it would need to be paged in. So, CPU (and perhaps disk) overhead is increased, but memory pressure remains the same.
The problem (a process touching too much memory) is real. However the solution does not work. A working-set cap doesn't actually reduce memory pressure on foreground applications any more than a per-second trim.
I'm running some monitoring that will tell me how setup.exe behaves on my machines. I tested it by forcing an update from Chrome. The private commit and private working set were 66.76 and 61.70 MiB, so no capping, but that makes sense because a user-initiated update isn't running at low priority, so we don't trigger background mode.
So, the only time the bug happens is for background updates that may be happening when the user isn't even present. And, since the CPU priority is low they won't harm responsiveness of foreground applications. But they will waste CPU time and electricity and battery life (if on battery). So, a silent waste.
What advantages would you get by being able to reserve memory with a finer than 64-KiB granularity? Especially with 64-bit Windows it seems quite unnecessary to have finer granularity. Am I missing something?
In what scenario would be 32 MiB working-set limit, enforced when pages are swapped in, be more effective at saving memory than a similar limit enforced by the once-per-second balance-set-manager?
Obviously trimming the working set at swap time does a better job of reducing the working set, but that's not what matters. What matters is saving memory. If you are trying to save memory then trimming once a second is just as good, and far more efficient, than trimming on every page fault.
But, trimming at all on a 64 GiB machine with 47 GiB free is just silly. It doesn't make sense to spend lots of an expensive resource (CPU time == electricity == battery life) in order to save a resource which you aren't even fully using.
I'll just reiterate what is said later on. The API is documented. However this extremely important effect of calling the API is not. We called the API expecting lower I/O priority and lower CPU priority or something like that. We perhaps expected lower memory priority. Really the documentation should have spelled all of this out.
But in addition to this we got a problematic working-set cap which can absolutely destroy performance. That detail needs to be documented (and the rest of the behavior should be as well).
It's a good question. It could be that most people don't notice this things, those who don't don't report it, etc. Or maybe it only affects some people, but I can't think how that could be true. More mysteries
Yep, that is generally what Windows does, using available memory for the disk cache. In the user trace the system had lots of disk cache (available memory) and lots of _free_ memory, so there really was zero value in trimming the working set.
But, (undocumented) rules gotta be followed, so trim the working set it is.
The foreground applications will still be paged out, only now they will be paged out for longer.
Without background mode setup.exe would have a 48 MiB working set, for a short period of time.
With background mode setup.exe has a 32 MiB working set, plus 16 MiB of its memory is bouncing back and forth between the working set and the standby list.
Thus, none of its memory will get paged out and foreground apps will get paged out, and this will continue for 250 times as long.
What's wrong with using 32 MiB of memory? That's a relatively small amount, especially if you're trying to patch a 225 MB DLL.
And I would argue that the 32 MiB is worse than arbitrary - it is pointless. I have been thinking about this for a while and I cannot think of a situation where it makes things better. It wastes (a lot of) CPU, and I claim that it doesn't actually save memory compared to letting the balance-set manager do the trimming.
Low CPU priority and low IO priority are important for being a polite background process. Not using too much memory is important. But a working-set cap fails to achieve that last goal.
There probably is a way to find what processes have this mode enabled, but it's probably more productive to search github for references to the problematic constant.