On Wed, 12 Oct 2011 15:43:17 +1100 Paul Mackerras <paulus@xxxxxxxxx> wrote: > In the meantime we have a user-triggerable kernel crash. As far as I > can see, if we did what you suggest, we would end up with a situation > where we could run out of huge pages even though everyone was within > quota. Which is arguably better than a kernel crash, but still less > than ideal. What do you suggest? My issue with the patch is that it's rather horrible. We have a layer of separation between core hugetlb pages and hugetlbfs. That layering has already been mucked up in various places and this patch mucks it up further, and quite severely. So I believe we should rethink the patch. Either a) get the layering correct by not poking into hugetlbfs internals from within hugetlb core via one of the usual techniques or b) make a deliberate decision to just give up on that layering: state that hugetlb and hugetlbfs are now part of the same subsystem. Make the necessaary Kconfig changes, remove ifdefs, move code around, etc. If we go ahead with the proposed patch-n-run bugfix, the bad code will be there permanently - nobody will go in and clean this mess up and the kernel is permanently worsened. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>