by nikbackm on 10/2/23, 6:09 AM with 100 comments
by jacobgorm on 10/4/23, 5:17 PM
The Windows BACKGROUND mode is useful for stuff like virus scanning or database log compaction, where you want to make some progress, but only if you can be certain not to hurt any foreground workloads. Back when we had hard drives, this wasn't actually trivial to achieve, because it is very easy to interfere with the foreground workload just by doing a few disk seeks every now and then.
I agree the 32MiB working setlimit is somewhat arbitrary and should be documented, but Windows is full of these arbitrary constants, like the 32kiB paging chunk for instance.
My recommendation for Chrome would be to stick with the background mode, and fix whatever problem is causing the working set to exceed 32MiB.
by Varriount on 10/2/23, 3:17 PM
> Trimming the working set of a process doesn’t actually save memory. It just moves the memory from the working set of the process to the standby list. Then, if the system is under memory pressure the pages in the standby list are eligible to be compressed, or discarded (if unmodified and backed by a file), or written to the page file. But “eligible” is doing a lot of heavy lifting in that sentence. The OS doesn’t immediately do anything with the page, generally speaking. And, if the system has gobs of free and available memory then it may never do anything with the page, making the trimming pointless. The memory isn’t “saved”, it’s just moved from one list to another. It’s the digital equivalent of paper shuffling.
I'd always been under the impression that as soon as memory was trimmed from the working set. Perhaps this was the case at some point, and was a reason for the PROCESS_MODE_BACKGROUND_BEGIN priority? As the blog mentions, the SetPriorityClass call has had this behavior since at least 2015, though I wouldn't be surprised if this behavior has existed for much longer.
As for why this "bug" hasn't been fixed, my guess is that it's due to a couple of factors:
- Windows has become fairly good over the years at keeping the core UI responsive even when the system is under heavy load.
- There are plenty of ways to reduce memory/CPU usage that don't involve a call to SetPriorityClass. I'd wager that setting a process's priority class is not the first thing that would come to mind.
- As a result of the previous two points, the actual number of programs using that call is quite small. I'd actually be interested in knowing what, if any, parts of Windows use it.
(As a side note, if there was a bug in a Windows API function, how would you even report it?
by criddell on 10/4/23, 6:00 PM
I’d love to learn more about ETW and your videos seem like a good place to start. If anybody else has other recommendations, please share!
by amluto on 10/5/23, 3:35 AM
(x86 has had “accessed” tracking for a long long time. What would be wrong with keeping over-the-working-set pages present but not “accessed” and tracking accesses without causing page faults? Or at least only trying to expire pages when there’s some degree of memory pressure.)
by NavinF on 10/2/23, 6:37 AM
by jrmg on 10/4/23, 3:56 PM
This sounds like it should be basically free in a memory-unconstrained system - is the system really just spending all its time managing these lists? Why is it so expensive?
by kristianp on 10/2/23, 8:22 AM
"This issue has been known for eight years, on many versions of Windows, and it still hasn’t been corrected or even documented. I hope that changes now."
by chrisbolt on 10/4/23, 3:44 PM
by Borg3 on 10/3/23, 8:05 AM
Another improvement from Microsoft without really understanding their own OS.
by tedunangst on 10/2/23, 11:40 PM
by Majromax on 10/4/23, 6:28 PM
by leptons on 10/4/23, 5:03 PM
by mrguyorama on 10/2/23, 5:32 PM
If the memory isn't owned by the OS, that's probably the wrong actor to manage it.
They say that, instead, they used an undocumented API they obviously didn't understand. Why? If you are concerned about using up too much memory, then do something about it