Deallocating memory pages

[Hiroshi Yamauchi]

> Yes, exactly; I'm trying to understand (for my own sake, really, but maybe others too) what this patch adds over letting kernel manage physical pages on its own given it has a better global view of the system.   madvise(MADV_DONTNEED) appears to actively unmap the pages, rather than just marking them (so, e.g., swap decisions can be made later about them); if there's no pressure/shortage for physical pages, this will just create unneeded overhead (both with this initial syscall and later if pages need to mapped again), won't it?

That's basically how the cost/benefit works out. If no other apps need
the RAM, no point. If they do, they may get to avoid the very
expensive swapping (which, I imagine, one would avoid at almost all
cost as the performance falls off a cliff with swapping) or be able to
run at all if swap is turned off, and win.

The question is how likely they need the RAM and whether you'd be
willing to pay the page deallocation cost to get this sort of memory
management flexibility. An alternative way to look at it, in my view,
is that it'd make it a little bit closer to how many C/C++
applications tend to behave in that they usually release a fair amount
of unused pages when they are less loaded (bugs and memory leaks
aside).

>
> Also, if an app has spikey usage but where spikes are frequent, this patch would probably be a net negative since it's not based on ergonomics/statistics/trend/etc.  Since your patch makes this new behavior "toggleable" it's probably not an issue.

You are probably right about that. It's currently based on a simple
strategy of deallocating pages as soon as they are freed (which might
be worth improving in the future.) And that'd probably be the
worst-case situation.

That said, there are a few side notes to keep in mind: As this feature
deallocates pages in the old generation only, the frequency of the
'spikes' that would add to the cost of this feature is limited by how
fast objects get allocated in the old gen (mostly promotions) and
freed by the old-gen collections. And if you have frequent spikes in
the old generation, there's a chance that you are having a
not-so-great GC behavior and if so, you'd probably like to avoid
either way. Also, even if there are spikes, as long as there's a gap
between the peaks of the spikes and the maximum heap size, there would
be some pages/RAM that this feature could deallocate and make
available to other apps.

And yes, the feature is disabled by default by a flag.