I am still opposed to this. The patchset results in compound pages be managed in 4k segments. The approach so far was that a compound page is simply a page struct referring to a larger linear memory segment. The compound state is exclusively modified in the first page struct which allows an easy conversion of code to deal with compound pages since the concept of handling a single page struct is preserved. The main difference between the handling of a 4K page and a compound pages page struct is that the compound flag is set. Here compound pages have refcounts in each 4k segment. Critical VM path can no longer rely on the page to stay intact since there is this on the fly conversion. The on the fly "atomic" conversion requires various forms of synchronization and modifications to basic VM primitives like pte management and page refcounting. I would recommend that the conversion between 2M and 4K page work with proper synchronization with all those handling references to the page. Codepaths handling huge pages should not rely on on the fly conversion but properly handle the various sizes. In most cases size does not matter since the page state is contained in a single page struct regardless of size. This patch here will cause future difficulties in making code handle compound pages. Transparent huge page support better be introduced gradually starting f.e. with the support of 2M pages for anonymous pages. -- 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>