Issue 595930  discussed the RESET-based impl's performance issues.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/42e65bf2e23d5d36994677dd630d2cf1b5fb86e0

commit 42e65bf2e23d5d36994677dd630d2cf1b5fb86e0
Author: Wez <wez@chromium.org>
Date: Wed Jul 19 23:12:05 2017

Break out platform-specific discardable paging into Lock/UnlockPages.

Refactor the DiscardableSharedMemory implementation to put platform-
native discardable page management in separate LockPages/UnlockPages
functions.

This isolates the platform-specific calls from internal details of the
DiscardableSharedMemory implementation, in particular the need to allow
for the space occupied by the SharedState structure.

Also corrects "lock page" platform API errors to return FAILED rather
than PURGED result, and adds some DCHECKing for "unlock page" API
errors.

Bug:  716205 
Change-Id: I572d65a0304816305053669ec81c78a3461d8325
Reviewed-on: https://chromium-review.googlesource.com/574901
Commit-Queue: Wez <wez@chromium.org>
Reviewed-by: David Reveman <reveman@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#488027}
[modify] https://crrev.com/42e65bf2e23d5d36994677dd630d2cf1b5fb86e0/base/memory/discardable_shared_memory.cc

+pennymac

Penny, you looked at Offer/Reclaim previously but found they sometimes failed with invalid-argument errors. Do you recall if there was any pattern to that, e.g. was it usually one or other other than failed? I found that they don't cope with operations of |length==0|, unsurprisingly, for example.

(also, see  issue 747657  - I'm seeing VirtualFree(MEM_DECOMMIT) consistently fail when I run tests locally).

Running some simple tests which:

1. Create a 1GB shared-memory instance.
2. Repeatedly (30 times in my test):
  a. Lock all the pages.
  b. Write to all the pages with memset().
  c. Unlock all the pages.
  d. Purge() all the pages.

gives a slow-down of 6x if we introduce Offer/Reclaim in the UnlockLock calls.

Introducing DiscardVirtualMemory() has no discernible impact on the speed of the 30 calls, but does cause the pages to be correctly discarded, so I suggest we just replace MEM_DECOMMIT with that in the Purge() impl.

FWIW the Offer/Reclaim CL can be found at https://chromium-review.googlesource.com/c/572484 though I'm abandoning it based on the poor performance.

I support shelving this cl for now as well.  Bruce actually helped me (~1.5 years ago?) do some ETW trace to see why the offer/reclaim was so damn slow.  I believe it was doing something to every page in the range.  Unfortunate.

I suppose nothing of consequence in the wild is (yet) using these APIs, and therefore MS haven't been pressured to fix the efficiency.

Re #9: Thanks for this and your input on the related DiscardVirtualMemory() change, pennymac@ - I agree, it does look like the calls have cost that scales linearly with the number of pages. I wonder if they assume the caller will use them lazily (i.e. only call Offer on a range that has not been actively touched in some time), rather than on every lock/unlock?  May also perform better on large-page ranges... ;)

I've noticed previously that freeing large blocks of memory (VirtualFree) has cost that is proportional to the number of pages in the allocation (well, to number of pages that were touched and therefore were paged in). I don't know enough to be sure how surprised I should be by this, but I'm definitely not surprised that DiscardVirtualMemory has the same behavior.

> I suppose nothing of consequence in the wild is (yet) using these APIs,
> and therefore MS haven't been pressured to fix the efficiency.

Obviously lots of applications use VirtualFree and I'll be that DiscardVirtualMemory would benefit if they ever optimized VirtualFree. I should do some Linux/Windows comparative profiling.

jschuh and I just chatted about this. To clarify - we currently believe that OfferVirtualMemory synchronously touches every page in the range, whereas VirtualFree only need to update the memory region, right? However, eventually, all the relevant pages still need to be updated by the Kernel, so maybe VirtualFree is just amortizing the cost whereas Offer/Reclaim is not?

If that's the case, maybe we should some state manager which, in the background, when not much else is happening, calls OfferVirtualMemory. [and does appropriately clever things in high-memory-pressure conditions, etc.].

Actually I believe that VirtualFree(MEM_DECOMMIT) did not appear to have a
significant overhead simply because it was always failing, due to being an
invalid operation to perform on pagefile-backed shared memory.