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
[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.

-- 
 Kirill A. Shutemov