On Mon, Apr 12, 2010 at 10:50:33AM +0300, Avi Kivity wrote: > The problem with hugetlbfs is that you need to commit upfront to using > it, and that you need to be the admin. For virtualization, you want to > use hugepages when there is no memory pressure, but you want to use ksm, > ballooning, and swapping when there is (and then go back to large pages > when pressure is relieved, e.g. by live migration). > > HPC and databases can probably live with hugetlbfs. JVM is somewhere in > the middle, they do allocate memory dynamically. I guess lots of the recent work on hugetlbfs has been exactly meant to try to make hugetlbfs more palatable by things like JVM, the end result is that it's growing in its own parallel VM but very still crippled down compared to the real kernel VM. I see very long term value in hugetlbfs, for example for CPUs that can't mix different page sizes in the same VMA, or for the 1G page reservation (no way we're going to slowdown everything increasing MAX_ORDER so much by default even if fragmentation issues wouldn't grow exponentially with the order) but I think hugetlbfs should remain simple and cover optimally these use cases, without trying to expand itself into the dynamic area of transparent usages where it wasn't designed to be used in the first place and where it's not a too good fit. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>