On Tue, Mar 01, 2016 at 03:09:19PM +0300, Kirill A. Shutemov wrote: > On Tue, Mar 01, 2016 at 11:51:36AM +0000, Mel Gorman wrote: > > While I know some of these points can be countered and discussed further, > > at the end of the day, the benefits to huge page usage are reduced memory > > usage on page tables, a reduction of TLB pressure and reduced TLB fill > > costs. Until such time as it's known that there are realistic workloads > > that cannot fit in memory due to the page table usage and workloads that > > are limited by TLB pressure, the complexity of huge pages is unjustified > > and the focus should be on the basic features working correctly. > > Size of page table can be limiting factor now for workloads that tries to > migrate from 2M hugetlb with shared page tables to DAX. 1G pages is a way > to lower the overhead. > That is only a limitation for users of hugetlbfs replacing hugetlbfs pages with DAX and even then only in the case where the workload is precisely sized to available memory. It's a potential limitation in a specialised configuration which may or may not be a problem in practice. Even the benefits of reduced memory usage and TLB pressure is not guaranteed to be offset by problems such as flushing the cache lines of the entire huge page during writeback or the necessity of allocating huge blocks on disk for a file that may or may not need it. Huge pages fix some problems but cause others. It may be better in practice for a workload to shrink the size of the shared region that was previously using hugetlbfs for example. Granted, I've not been following the development of persistent memory closely but from what I've seen, I think it's more important to get persistent memory, DAX and related features working correctly first and then worry about page table memory usage and TLB pressure *if* it's a problem in practice. If there are problems with fault scalability then it would be better to fix that instead of working around it with huge pages. -- Mel Gorman SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
