On Mon, 2019-06-10 at 15:02 -0700, Dave Hansen wrote: > On 6/10/19 1:58 PM, Yu-cheng Yu wrote: > > > > 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
