> We thought about this too, but in some special cases, we do not know the > correct page size of a memory range. For example when getting a 16M chunk > from a 16M huge page region which is also aligned to 16M, the first madvise() > will work fine and the code will assume that the page size is 64K.
I see ... yes, that does break my idea completely. OK, another half-baked idea: what if we pay attention to when madvise(DOFORK) fails as well as well madvise(DONTFORK) fails, and use that as a hit that we better check the page size? Perhaps this adds too much complexity ... in which case your idea: > As this issue was not present in version 2 of the code, but there we had > a big performance penalty, I suggest the following: we could go back to > version 2 and introduce a new RDMAV_HUGEPAGE_SAFE env variable to let the > user > decide between huge page support and better performance (the same approach we > use for the COW protection itself). seems like a reasonable alternative. Thanks, Roland -- Roland Dreier <rola...@cisco.com> || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html