On Wed, Nov 6, 2013 at 10:34 PM, Ben Kloosterman <[email protected]> wrote:
> This is an interesting technique. Get 2 large pages release and put a > guard page there. It will not cause much worse fragmentation than if the > pages were consecutive. > > p = mmap(NULL, 2 << 21, PROT_X, MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB, > -1, 0); > mremap(p, 2 << 21, 1 << 21, 0); > mmap(p + (1 << 21), 1 << 12, PROT_X, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, > -1, 0); > > Also note the heap could use some large pages but this would be more > annoying with guard pages in the heap. > So if I'm reading that one right, you don't end up with a large TLB mapping, because the mremap shrinks the page. The goal isn't to use a big space. The goal is to use a large TLB mapping *in the TLB*. I don't buy that holes in the heap are that big a deal. You need a virtual range allocator under all of this anyway.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
