> > If you don't use a guard page, you kinda have to do the stack checks. > There several two possible reasons *not* to use a guard page: > > 1. You are executing in a non-paged environment > 2. You really think that virtual address space is at a premium > 3. You think that large-page TLBs matter > > But the way to think about this is that frame allocation on the stack is > just bump allocation. The real issue with stack segmentation is the fact > that the bump allocation will repeatedly take the long path at the stack > segment boundary unless you are prepared to grow the stack. > > I dont buy 2 and im iffy on 3.
The long path should not matter so much compared to memory operations in a new area. Anyway for optimal functions you can still allow the initial stack size to be set manually eg you may want 4K if you use lots of threads or 2 Meg if you call some native lib which uses recursion . The guard page will just handle unusual cases and mistakes so its not a case of guard page/ segment or standard stack but standard stack and guard page . You can run a large initial page and a guard page , maybe an option for the first thread in an app , but i think its only worth it if you access items deep in the stack eg by having a region there. large page TLB do matter but in a stack normally only the last page or 2 is hot. 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. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
