On Wed, 9 Sep 2009, Mel Gorman wrote: > And to beat a dead horse, it does make sense that an application > allocating hugepages obey memory policies. It does with dynamic hugepage > resizing for example. It should have been done years ago and > unfortunately wasn't but it's not the first time that the behaviour of > hugepages differed from the core VM. > I agree completely, I'm certainly not defending the current implementation as a sound design and I too would have preferred that it have done the same as Lee's patchset from the very beginning. The issue I'm raising is that while we both agree the current behavior is suboptimal and confusing, it is the long-standing kernel behavior. There are applications out there that are written to allocate and free hugepages and now changing the pool from which they can allocate or free to could be problematic. I'm personally fine with the breakage since I'm aware of this discussion and can easily fix it in userspace. I'm more concerned about others leaking hugepages or having their boot scripts break because they are allocating far fewer hugepages than before. The documentation (Documentation/vm/hugetlbpage.txt) has always said /proc/sys/vm/nr_hugepaegs affects hugepages on a system level and now that it's changed, I think it should be done explicitly with a new flag than implicitly. Would you explain why introducing a new mempolicy flag, MPOL_F_HUGEPAGES, and only using the new behavior when this is set would be inconsistent or inadvisible? Since this is a new behavior that will differ from the long-standing default, it seems like it warrants a new mempolicy flag to avoid all userspace breakage and make hugepage allocation and freeing with an underlying mempolicy explicit. This would address your audience that have been (privately) emailing you while confused about why the hugepages being allocated from a global tunable wouldn't be confined to their mempolicy. -- To unsubscribe from this list: send the line "unsubscribe linux-numa" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
