On Tue, Mar 19, 2019 at 1:45 AM Kirill A. Shutemov <kirill@xxxxxxxxxxxxx> wrote: > > On Wed, Mar 13, 2019 at 09:07:13AM -0700, Dan Williams wrote: > > On Wed, Mar 6, 2019 at 4:46 AM Aneesh Kumar K.V > > <aneesh.kumar@xxxxxxxxxxxxx> wrote: > > > > > > On 3/6/19 5:14 PM, Michal Suchánek wrote: > > > > On Wed, 06 Mar 2019 14:47:33 +0530 > > > > "Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxxxxx> wrote: > > > > > > > >> Dan Williams <dan.j.williams@xxxxxxxxx> writes: > > > >> > > > >>> On Thu, Feb 28, 2019 at 1:40 AM Oliver <oohall@xxxxxxxxx> wrote: > > > >>>> > > > >>>> On Thu, Feb 28, 2019 at 7:35 PM Aneesh Kumar K.V > > > >>>> <aneesh.kumar@xxxxxxxxxxxxx> wrote: > > > > > > > >> 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?
