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.