I think there is a misunderstanding here: The GC freeing unused memory is good. It is of no use to keep it around just to see a higher number in the WS metric... You don't want unused memory in the WS. You are optimizing for the wrong metric.
The number of page faults is not that meaningful because there are soft and hard faults. Hard faults read from disk. Soft faults mean nothing in most cases. They are an implementation detail of the OS. For example, for every newly allocated page you touch a soft fault occurs.
Here is some evidence that your red graph is not showing hard faults: At the end it shows about 500/sec. Your disk cannot deliver 500 IOPs so it cannot be hard faults.
You probably want to measure (and reduce) hard faults only. Only hard faults impact performance in a meaningful way.
Also, setting WS limits does not influence what the GC does. The GC is not an operating system component. Is is a user-mode library. It has nothing to do with what the OS decides to use as the working set. For that reason you cannot make the GC not release memory by setting WS limits.
So why does the WS shrink when the GC runs? Because the GC deletes some memory. Setting some WS limit cannot prevent deletion of memory.
In the comments it was suggested the GC might itself call some API to shrink the working set. I cannot see any reason at all why it would do that. Why would the GC force pages out of the process? Remember: WS and allocated pages are not the same (at all!). The GC might release memory. It does not force the WS to shrink. What purpose would that have?
