On Mon, 2019-06-10 at 15:02 -0700, Dave Hansen wrote:
On 6/10/19 1:58 PM, Yu-cheng Yu wrote:
quoted
quoted
quoted
On each memory request, the kernel then must consider a percentage of
allocated space in its calculation, and on systems with less memory
this quickly becomes a problem.
I'm not sure what you're referring to here? Are you referring to our
overcommit limits?
Yes.
My assumption has always been that these large, potentially sparse
hardware tables *must* be mmap()'d with MAP_NORESERVE specified. That
should keep them from being problematic with respect to overcommit.
Ok, we will go back to do_mmap() with MAP_PRIVATE, MAP_NORESERVE and
VM_DONTDUMP. The bitmap will cover only 48-bit address space.
We then create PR_MARK_CODE_AS_LEGACY. The kernel will set the bitmap, but it
is going to be slow.
Perhaps we still let the app fill the bitmap?
Yu-cheng