Deallocating memory pages

[Vitaly Davidovich]

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?

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.

Thanks

Sent from my phone
On Jan 28, 2013 6:28 PM, "Hiroshi Yamauchi" <yamauchi at google.com> wrote:

>
>
>
> On Fri, Jan 25, 2013 at 3:29 PM, Vitaly Davidovich <vitalyd at gmail.com>wrote:
>
>> Hiroshi,
>>
>> I'll second your explanation for #1 - we also have some server workloads
>> that fluctuate.
>>
>> Since the kernel will page out memory if need arises on its own, the main
>> benefit I'm seeing in your patch is that it removes the possibility that
>> kernel will page out the wrong pages.  That is, if it's using LRU page
>> replacement (or whatever the latest heuristic might be) and GC just freed
>> up those pages (but ended up marking them dirty in the process), then if
>> kernel needs to swap out it may overlook these pages because they don't fit
>> the replacement policy(I guess it also ensures that these pages don't need
>> swap backing either). Otherwise, if the server app has not been using those
>> extra pages for a while anyway, I'm thinking kernel will pick up on that.
>>
>> Is that right? Just want to make sure I understand.
>>
> Vitaly, do you mean that without this feature/patch, the kernel might
> choose to swap out a page with valid data as opposed to a page that has
> garbage data and would have been deallocated with this feature/patch if it
> follows an LRU-like policy or something similar? If so, you are probably
> right about that.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130128/405fad73/attachment.htm>