Re: [Lsf-pc] [LSF/MM TOPIC] Support for 1GB THP

[Mel Gorman <mgorman@suse.de>]

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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>