[HN Gopher] MiB Working Sets on a 64 GiB machine
___________________________________________________________________
MiB Working Sets on a 64 GiB machine
Author : ingve
Score : 36 points
Date : 2023-10-02 06:39 UTC (16 hours ago)
(HTM) web link (randomascii.wordpress.com)
(TXT) w3m dump (randomascii.wordpress.com)
| ciupicri wrote:
| Why was the title truncated? The original one - "32 MiB Working
| Sets on a 64 GiB machine" - makes more sense.
| danjc wrote:
| It was trimmed to save memory
| Varriount wrote:
| I found this paragraph particularly interesting:
|
| > 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?
| Bjartr wrote:
| > Windows has become fairly good over the years at keeping the
| core UI responsive even when the system is under heavy load.
|
| I would say that's debatable. There are fewer complete freezes
| that require a restart, but things like the task manager (can't
| get much more core than that), which used to be instantly
| available and responsive if the machine was recoverable at all,
| now can take tens of seconds to show up and and respond to
| interactions under heavy load.
| mrguyorama wrote:
| I'm not sure I understand, why not just manage your own memory
| instead of asking the OS to magically understand your memory use-
| case and properly manage/limit?
|
| 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_
___________________________________________________________________
(page generated 2023-10-02 23:02 UTC)