On Tue, 2007-01-23 at 17:18 +1100, David Gibson wrote: > Second, there's the fact that we never demote hugepage segments back > to normal pages. That was a deliberate decision to keep things > simple, incidentally, not simply an oversight. I guess it would help > in this case and shouldn't be that hard. It would mean a find_vma() > on each unmap to see if the region is now clear, but that's probably > not too bad. Plus a bunch of on_each_cpu()ed slbies as when we open a > new hugepage segment. Oh.. and making sure we get rid of any empty > hugepage directories, which might be a bit fiddly.
Could we also try lazy conversion of huge segments to normal ones? When is_hugepage_only_range() detects overlapping hugepage ranges, it could attempt to "close" those ranges for huge pages first. Then the heavy lifting only needs to happen when a small page mapping needs the space. -- Adam Litke - (agl at us.ibm.com) IBM Linux Technology Center ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Libhugetlbfs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
