Hacker News Reader

Comment by jacobgorm | Hacker News Reader

The background mode is not hurting anyone, it is the thrashing process that is hurting itself by using too much memory. This shows up as high CPU but, because it is in the background, the rest of the system performance should be largely unaffected. Anything with foreground priority will still be scheduled to run whenever it needs to.

Had the background process been allowed to keep growing its working set then foreground applications would be forced to page out, defeating the goal of having a background mode in the first place.

View on HN

Doing useless work nobody asked for is always a problem. People use systems with batteries and they would appreciate their system not doing that.

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.

The foreground processes will always get scheduled ahead of the background process, and be able steal its evicted pages from the Standby list, thus reducing their own need for paging to external media.

If all you care about is getting your updater to complete quicker, you should not be using the background mode, but ideally the Chrome updater would run in the background without affecting the performance of the foreground applications. Allowing for working set peaks, no matter how short, will fail to achieve that on systems experiencing memory pressure.

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.

> This shows up as high CPU but, because it is in the background, the rest of the system performance should be largely unaffected.

And, as said, draining your battery for no good reason.

> Had the background process been allowed to keep growing its working set then foreground applications would be forced to page out

Why would they? As said, you could still page out the processes running in background mode first if you actually start running out of memory. And if after trimming all the background processes to 32mb you still don't have enough memory, you would be in the same situation either way.

The current implementation has absolutely no advantage.

But the limit of 32 MB is arbitrary and undocumented which is a huge problem.

Reply on news.ycombinator.com