On Wed, Jul 26, 2017 at 10:39:30AM -0700, Mike Kravetz wrote: > In the overview of this RFC, I mentioned still needing to address the > comment from Aneesh about splitting SHM_HUGE_* definitions into arch > specific header files. This is how it is done for mmap. If an arch > supports multiple huge page sizes, the 'asm/mman.h' contains definitions > for those sizes. There will be a bit of churn (such as header file > renaming) to do this for shm as well. So, I keep going back and forth > asking myself 'is it worth it'? Some things to consider. > > - We should be consistent between mmap and shm. Also remember, that I > will propose adding the same type of encoding to memfd_create. So, > three system calls will use the encoding. They should be consistent. I think mmap is wrong here. User programs are generally not architecture specific, so they'll have to test with ifdefs or something awful. For all we know, POWER 14 and whatever x86 CPU comes out in 2030 will support (nearly) arbitrary page sizes like Itanium does, and a user program compiled today should be able to take advantage of it. > - Adding the arch specific definitions seems the 'most correct', as a > user can not use a definition not supported by the arch. However, > even if an arch supports a huge page size it does not mean that the > running kernel supports that size. Therefore, the folllowing is in > the man page. > "The range of huge page sizes that are supported by the system > can be discovered by listing the subdirectories in > /sys/kernel/mm/hugepages." > - Another alternative is to make all known huge page sizes available > to all users. This is 'easier' as the definitions can likely reside > in a common header file. The user will need to determine what > huge page sizes are supported by the running kernel as mentioned in > the man page. That's my preference. -- 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/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
