-
Notifications
You must be signed in to change notification settings - Fork 4.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VirtualReserve is allocating 256GB on illumos rather than "reserving" #104211
Comments
Actually |
It looks like we might be better off using sysconf on Linux as well.
And comparing results:
so it appears that on Linux, that sysconf gets you MemFree. I ran this on a VM with 8BG physical ram. That 7+ GB of RAM reported by MemAvailable is questionable, but maybe that's the right thing to use on Linux. I'm not sure. |
Not sure I understood why it is requiring us to set |
Here is similar data for an 8GB VM running illumos:
And here's what that sysconf says:
So a little over 4GB free memory. |
OK, when illumos actually uses Have a look at the latest in this comparison. This is for debugging. Rather than bother with config variables for I'm not sure what went wrong with the config variables, but apparently something did. |
Is it not using sysconf without the change (i.e. ReadMemAvailable() returns false on illumos and we hit the fallback)? IOW, is this change saving us from setting |
Looks like my changes were unnecessary. I must have been confused somehow. Maybe running a different build than I thought? Anyway the
That was running with this code: I guess we can close this issue. Thanks. |
Thank you for confirming. Glad to know that we don't need
It would be nice if we could call mlock under vfork() as you suggested (am11@f132097?w=1) or other types of fork/clone to see if it emulates IPI and saves us from requiring mlock privileges. That would fix couple of issues with linux and freebsd jail as well (e.g. #44417). Dealing with |
It turns out |
Could you please open a pull request with that change? |
Need MAP_NORESERVE for the 256G mmap calls on illumos (and maybe some other platforms)
Need MAP_NORESERVE for the 256G mmap calls on illumos (and maybe some other platforms)
Need MAP_NORESERVE for the 256G mmap calls on illumos (and maybe some other platforms)
The PR is up. 104275 |
Need MAP_NORESERVE for the 256G mmap calls on illumos, (and maybe some other platforms) otherwise it tries to allocate physical pages, which will fail on most VMs.
Need MAP_NORESERVE for the 256G mmap calls on illumos, (and maybe some other platforms) otherwise it tries to allocate physical pages, which will fail on most VMs.
Need MAP_NORESERVE for the 256G mmap calls on illumos, (and maybe some other platforms) otherwise it tries to allocate physical pages, which will fail on most VMs.
Need MAP_NORESERVE for the 256G mmap calls on illumos, (and maybe some other platforms) otherwise it tries to allocate physical pages, which will fail on most VMs.
Split from #34944 (comment)
We should improve this implementation to support illumos properly, so it doesn't require setting the upper limit for heap memory alloc.
With linux procfs we get more accurate or up-to-date stats than sysconf. That's why it's only used in fallback. Since on illumos procfs is binary based, it bails out early from
ReadMemAvailable()
function.If there are similar concerns with sysconf() on illumos, kstat might be more accurate; something like this:
The text was updated successfully, but these errors were encountered: