Re: [PATCH 2/2] mm/dax: Don't enable huge dax mapping by default
From: Dan Williams <hidden>
Date: 2019-03-19 15:36:54
Also in:
linux-mm, lkml, nvdimm
On Tue, Mar 19, 2019 at 1:45 AM Kirill A. Shutemov [off-list ref] wrote:
On Wed, Mar 13, 2019 at 09:07:13AM -0700, Dan Williams wrote:quoted
On Wed, Mar 6, 2019 at 4:46 AM Aneesh Kumar K.V [off-list ref] wrote:quoted
On 3/6/19 5:14 PM, Michal Suchánek wrote:quoted
On Wed, 06 Mar 2019 14:47:33 +0530 "Aneesh Kumar K.V" [off-list ref] wrote:quoted
Dan Williams [off-list ref] writes:quoted
On Thu, Feb 28, 2019 at 1:40 AM Oliver [off-list ref] wrote:quoted
On Thu, Feb 28, 2019 at 7:35 PM Aneesh Kumar K.V [off-list ref] wrote:quoted
Also even if the user decided to not use THP, by echo "never" > transparent_hugepage/enabled , we should continue to map dax fault using huge page on platforms that can support huge pages.Is this a good idea? This knob is there for a reason. In some situations having huge pages can severely impact performance of the system (due to host-guest interaction or whatever) and the ability to really turn off all THP would be important in those cases, right?My understanding was that is not true for dax pages? These are not regular memory that got allocated. They are allocated out of /dev/dax/ or /dev/pmem*. Do we have a reason not to use hugepages for mapping pages in that case?The problem with the transparent_hugepage/enabled interface is that it conflates performing compaction work to produce THP-pages with the ability to map huge pages at all.That's not [entirely] true. transparent_hugepage/defrag gates heavy-duty compaction. We do only very limited compaction if it's not advised by transparent_hugepage/defrag. I believe DAX has to respect transparent_hugepage/enabled. Or not advertise its huge pages as THP. It's confusing for user.
What does "advertise its huge pages as THP" mean in practice? I think it's confusing that DAX, a facility that bypasses System RAM, is affected by a transparent_hugepage flag which is a feature for combining System RAM pages into larger pages. For the same reason that transparent_hugepage does not gate / control hugetlb operation is the same reason that transparent_hugepage should not gate / control DAX. A global setting to disable opportunistic large page mappings of System-RAM makes sense, but I don't see why that should read on DAX?