[Webkit-unassigned] [Bug 65766] [GTK] OSAllocator::reserveUncommitted should not commit physical memory

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=65766


Matthew Dempsky <mdempsky at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mdempsky at google.com




--- Comment #17 from Matthew Dempsky <mdempsky at google.com>  2012-09-17 13:14:39 PST ---
> "ulimit -m" limits the memory size. "ulimit -v" limits virtual memory.

So OpenBSD doesn't have this distinction.  We [OpenBSD] don't currently support unreserved mappings, nor do we have any intention to currently.  E.g., we don't have a MAP_NORESERVE flag for mmap() or any kernel knobs analogous to overcommit_memory/overcommit_ratio, and there's no -v option for our ulimit.

That said, I think it would be reasonable for us to still support PROT_NONE + MAP_NORESERVE mappings just for the purpose of reserving an (inaccessible) region of virtual memory that doesn't count against the process's used memory limit and with the guarantee that mmap() won't try to reuse that memory later unless explicitly requested to (i.e., with MAP_FIXED).  Is that adequate for WebKit's needs?

To be explicit, I'm envisioning syscalls like this on OpenBSD:

  p = mmap(0, 1 << 20, PROT_NONE, MAP_ANON | MAP_NORESERVE, -1, 0);
  /* [p, p+1M) is still unusable, but the OS will not reuse it for something else */

  mmap(p + 65536, 16384, PROT_READ | PROT_WRITE, MAP_ANON | MAP_FIXED, -1, 0);
  /* [p+64k, p+80k) is now readable+writable and counts as 16k against process resource limit; call might instead fail though if resources are exhausted */

  mmap(p + 65536, 8192, PROT_NONE, MAP_ANON | MAP_NORESERVE | MAP_FIXED, -1, 0);
  /* remap [p+64k, p+72k) as noreserve, effectively freeing it except for OS reuse guarantees; [p+72k, p+80k) is still usable and counts as only 8k against resource limits */

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.