Skip to contentSkip to conversation

thp: enforcing constraints on file thps

DISCUSSION Zach O'Keefe 2 participants 3 messages Jun 29, 2022 Memory management

lore
Share & tools
lore
#0 lore raw

Hey All,

There are currently a number of paths where we can collapse file memory into THPs:

1a) khugepaged - target of vma being processed
1b) khugepaged - other vma found mapping file, able to lock mmap_lock in
retract_page_tables()
1b) khugepaged - other vma found mapping file, deferred pte-mapped THP collapse,
processed in collapse_pte_mapped_thp()
2) page fault finds hugepage in page cache + filemap_map_pages()

In terms of system-enforced THP constraints:

* vma flags + thps sysfs settings

Checked in 1a. (1b now at least respects "never" THP mode after Yang Shi's cleanup series, but still doesn't respect "madvise" THP mode)

* MMF_DISABLE_THP

Checked in 1a and 1b

I'm wondering if we should align these, and if so, in what direction? I would argue that a process marked MMF_DISABLE_THP, or a vma marked VM_NOHUGEPAGE, probably shouldn't be mapping at the pmd level, and that the appropriate checks should be added in those paths.

Thanks,
Zach

#1 lore raw
Quoted 20 lines · Zach O'Keefe

Hey All,

There are currently a number of paths where we can collapse file memory into THPs:

1a) khugepaged - target of vma being processed
1b) khugepaged - other vma found mapping file, able to lock mmap_lock in
retract_page_tables()
1b) khugepaged - other vma found mapping file, deferred pte-mapped THP collapse,
processed in collapse_pte_mapped_thp()
2) page fault finds hugepage in page cache + filemap_map_pages()

In terms of system-enforced THP constraints:

* vma flags + thps sysfs settings

Checked in 1a. (1b now at least respects "never" THP mode after Yang Shi's cleanup series, but still doesn't respect "madvise" THP mode)

Quoted 8 lines

* MMF_DISABLE_THP

Checked in 1a and 1b

I'm wondering if we should align these, and if so, in what direction? I would argue that a process marked MMF_DISABLE_THP, or a vma marked VM_NOHUGEPAGE, probably shouldn't be mapping at the pmd level, and that the appropriate checks should be added in those paths.

That depends on how we explain the semantics of MMF_DISABLE_THP and VM_NOHUGEPAGE IMHO. They definitely prevent from allocating/collapsing new THPs for that process or vma, but shall they also prevent from mapping existing THPs to PMD? Maybe not.

Quoted 3 lines

Thanks,
Zach

#2 lore raw
Quoted 31 lines · Yang Shi
Quoted 20 lines · Zach O'Keefe

Hey All,

There are currently a number of paths where we can collapse file memory into THPs:

1a) khugepaged - target of vma being processed
1b) khugepaged - other vma found mapping file, able to lock mmap_lock in
retract_page_tables()
1b) khugepaged - other vma found mapping file, deferred pte-mapped THP collapse,
processed in collapse_pte_mapped_thp()
2) page fault finds hugepage in page cache + filemap_map_pages()

In terms of system-enforced THP constraints:

* vma flags + thps sysfs settings

Checked in 1a. (1b now at least respects "never" THP mode after Yang Shi's cleanup series, but still doesn't respect "madvise" THP mode)

Quoted 8 lines

* MMF_DISABLE_THP

Checked in 1a and 1b

I'm wondering if we should align these, and if so, in what direction? I would argue that a process marked MMF_DISABLE_THP, or a vma marked VM_NOHUGEPAGE, probably shouldn't be mapping at the pmd level, and that the appropriate checks should be added in those paths.

Quoted 4 lines

That depends on how we explain the semantics of MMF_DISABLE_THP and VM_NOHUGEPAGE IMHO. They definitely prevent from allocating/collapsing new THPs for that process or vma, but shall they also prevent from mapping existing THPs to PMD? Maybe not.

Hey Yang, thanks for your thoughts.

IIUC, you're basically saying things are working as intended? I see the argument that, if the THP is already assembled, we might as well just map it at the PMD level..

But as you mention, it weakens the API contract of MMF_DISABLE_THP and sysfs THP settings.

I don't have any real world example where this is an issue, and am tempted to kick this down the road until someone has a good reason to change it - but at the same time - the exasperation incurred by all end users isn't guaranteed to reach linux-mm.

Thanks,
Zach

Quoted 3 lines
Quoted 3 lines

Thanks,
Zach