> On Jun 18, 2019, at 2:12 PM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, 14 Jun 2019 11:22:01 -0700 Song Liu <songliubraving@xxxxxx> wrote: > >> This set follows up discussion at LSF/MM 2019. The motivation is to put >> text section of an application in THP, and thus reduces iTLB miss rate and >> improves performance. Both Facebook and Oracle showed strong interests to >> this feature. >> >> To make reviews easier, this set aims a mininal valid product. Current >> version of the work does not have any changes to file system specific >> code. This comes with some limitations (discussed later). >> >> This set enables an application to "hugify" its text section by simply >> running something like: >> >> madvise(0x600000, 0x80000, MADV_HUGEPAGE); >> >> Before this call, the /proc/<pid>/maps looks like: >> >> 00400000-074d0000 r-xp 00000000 00:27 2006927 app >> >> After this call, part of the text section is split out and mapped to THP: >> >> 00400000-00425000 r-xp 00000000 00:27 2006927 app >> 00600000-00e00000 r-xp 00200000 00:27 2006927 app <<< on THP >> 00e00000-074d0000 r-xp 00a00000 00:27 2006927 app >> >> Limitations: >> >> 1. This only works for text section (vma with VM_DENYWRITE). >> 2. Once the application put its own pages in THP, the file is read only. >> open(file, O_WRITE) will fail with -ETXTBSY. To modify/update the file, >> it must be removed first. > > Removed? Even if the original mmap/madvise has gone away? hm. > > I'm wondering if this limitation can be abused in some fashion: mmap a > file to which you have read permissions, run madvise(MADV_HUGEPAGE) and > thus prevent the file's owner from being able to modify the file? Or > something like that. What are the issues and protections here? > I found a better solution to this limitation. Please refer to changes in v3 (especially 6/6). Thanks, Song
