On 6/7/19 1:40 PM, Andy Lutomirski wrote: >>> Hmm. Can we be creative and skip populating it with zeros? The >>> CPU >> should only ever touch a page if we miss an ENDBR on it, so, in >> normal operation, we don’t need anything to be there. We could try >> to prevent anyone from *reading* it outside of ENDBR tracking if we >> want to avoid people accidentally wasting lots of memory by forcing >> it to be fully populated when the read it. >> >> Won't reads on a big, contiguous private mapping get the huge zero >> page anyway? > > The zero pages may be free, but the page tables could be decently large. Does the core mm code use huge, immense, etc huge zero pages? Or can it synthesize them by reusing page table pages that map zeros? IIRC, we only ever fill single PMDs, even though we could gang a pmd page up and do it for 1GB areas too. I guess the page table consumption could really suck if we had code all over the 57-bit address space and that code moved around and the process ran for a long long time. Pathologically, we need a ulong/pmd_t for each 2MB of address space which is 8*2^56-30=512GB per process. Yikes. Right now, we'd at least detect the memory consumption and OOM-kill the process(es) eventually. But, that's not really _this_ patch's problem. It's a general problem, and doesn't even require the zero page to be mapped all over. Longer-term, I'd much rather see us add some page table reclaim mechanism that new how to go after things like excessive page tables in MAP_NORESERVE areas.
