On Thu, Sep 6, 2018 at 2:36 PM Mike Kravetz <mike.kravetz@xxxxxxxxxx> wrote: > > On 09/05/2018 06:58 PM, Huang, Ying wrote: > > Hi, Christopher, > > > > Christopher Lameter <cl@xxxxxxxxx> writes: > > > >> On Tue, 4 Sep 2018, Daniel Jordan wrote: > >> > >>> - Promoting huge page usage: With memory sizes becoming ever larger, huge > >>> pages are becoming more and more important to reduce TLB misses and the > >>> overhead of memory management itself--that is, to make the system scalable > >>> with the memory size. But there are still some remaining gaps that prevent > >>> huge pages from being deployed in some situations, such as huge page > >>> allocation latency and memory fragmentation. > >> > >> You forgot the major issue that huge pages in the page cache are not > >> supported and thus we have performance issues with fast NVME drives that > >> are now able to do 3Gbytes per sec that are only possible to reach with > >> directio and huge pages. > > > > Yes. That is an important gap for huge page. Although we have huge > > page cache support for tmpfs, we lacks that for normal file systems. > > > >> IMHO the huge page issue is just the reflection of a certain hardware > >> manufacturer inflicting pain for over a decade on its poor users by not > >> supporting larger base page sizes than 4k. No such workarounds needed on > >> platforms that support large sizes. Things just zoom along without > >> contortions necessary to deal with huge pages etc. > >> > >> Can we come up with a 2M base page VM or something? We have possible > >> memory sizes of a couple TB now. That should give us a million or so 2M > >> pages to work with. > > > > That sounds a good idea. Don't know whether someone has tried this. > > IIRC, Hugh Dickins and some others at Google tried going down this path. > There was a brief discussion at LSF/MM. It is something I too would like > to explore in my spare time. Almost: I never tried that path myself, but mentioned that Greg Thelen had. Hugh
