<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 9, 2015 at 11:12 PM, Mark Hahn <span dir="ltr"><<a href="mailto:hahn@mcmaster.ca" target="_blank">hahn@mcmaster.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">overcommitment from happening. Available pages are checked on malloc, but<br>
if a process never touches a page it mallocs, then it isn't subtracted out<br>
of the available pages. So, if you want to be sure not to overcommit, make<br>
sure apps use calloc, mlock, or walk over their pages as soon as possible.<br>
Please correct me if I'm wrong on that.<br>
</blockquote>
<br></span>
pretty much just the opposite, I'm afraid.  vm.overcommit_memory=2<br>
means that VM allocations will be counted at at brk/mmap time<br>
against /proc/meminfo:CommitLimit.  this is good, because it means your allocation will fail, rather than some later time when you touch pages within it.<br>
<br>
in other words, the accounting is via VSZ, rather than RSS.<br></blockquote></div><br><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">​Good. I'm glad I was wrong.​​</div><br><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">​Do you know if remote swap is working well now? I remember it working not so good because it's a difficult problem, but I haven't tested it lately.​</div><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Andrew Shewmaker</div>
</div></div>