| Message ID | 20180612143915.68065-3-kirill.shutemov@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 06/12/2018 07:39 AM, Kirill A. Shutemov wrote: > Pages for encrypted VMAs have to be allocated in a special way: > we would need to propagate down not only desired NUMA node but also > whether the page is encrypted. > > It complicates not-so-trivial routine of huge page allocation in > khugepaged even more. It also puts more pressure on page allocator: > we cannot re-use pages allocated for encrypted VMA to collapse > page in unencrypted one or vice versa. > > I think for now it worth skipping encrypted VMAs. We can return > to this topic later. You're asking for this to be included, but without a major piece of THP support. Is THP support unimportant for this feature? Are we really asking the x86 maintainers to merge this feature with this restriction in place?
On Wed, Jun 13, 2018 at 05:50:24PM +0000, Dave Hansen wrote: > On 06/12/2018 07:39 AM, Kirill A. Shutemov wrote: > > Pages for encrypted VMAs have to be allocated in a special way: > > we would need to propagate down not only desired NUMA node but also > > whether the page is encrypted. > > > > It complicates not-so-trivial routine of huge page allocation in > > khugepaged even more. It also puts more pressure on page allocator: > > we cannot re-use pages allocated for encrypted VMA to collapse > > page in unencrypted one or vice versa. > > > > I think for now it worth skipping encrypted VMAs. We can return > > to this topic later. > > You're asking for this to be included, but without a major piece of THP > support. Is THP support unimportant for this feature? > > Are we really asking the x86 maintainers to merge this feature with this > restriction in place? I gave it more thought after your comment and I think I see a way to get khugepaged work with memory encryption. Let me check it tomorrow.
On 06/13/2018 01:18 PM, Kirill A. Shutemov wrote: >> Are we really asking the x86 maintainers to merge this feature with this >> restriction in place? > I gave it more thought after your comment and I think I see a way to get > khugepaged work with memory encryption. So should folks be reviewing this set, or skip it an wait on your new set?
On Wed, Jun 13, 2018 at 08:20:28PM +0000, Dave Hansen wrote: > On 06/13/2018 01:18 PM, Kirill A. Shutemov wrote: > >> Are we really asking the x86 maintainers to merge this feature with this > >> restriction in place? > > I gave it more thought after your comment and I think I see a way to get > > khugepaged work with memory encryption. > > So should folks be reviewing this set, or skip it an wait on your new set? You gave me fair bit of feedback to work on, but AFAICS it doesn't change anything fundamentally. More feedback is welcome.
diff --git a/include/linux/mm.h b/include/linux/mm.h index 1c3c15f37ed6..435b053c457c 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -1492,6 +1492,13 @@ static inline bool vma_is_anonymous(struct vm_area_struct *vma) return !vma->vm_ops; } +#ifndef vma_is_encrypted +static inline bool vma_is_encrypted(struct vm_area_struct *vma) +{ + return false; +} +#endif + #ifndef vma_keyid static inline int vma_keyid(struct vm_area_struct *vma) { diff --git a/mm/khugepaged.c b/mm/khugepaged.c index d7b2a4bf8671..a03b40bef033 100644 --- a/mm/khugepaged.c +++ b/mm/khugepaged.c @@ -835,6 +835,8 @@ static bool hugepage_vma_check(struct vm_area_struct *vma) return false; if (is_vma_temporary_stack(vma)) return false; + if (vma_is_encrypted(vma)) + return false; return !(vma->vm_flags & VM_NO_KHUGEPAGED); }
Pages for encrypted VMAs have to be allocated in a special way: we would need to propagate down not only desired NUMA node but also whether the page is encrypted. It complicates not-so-trivial routine of huge page allocation in khugepaged even more. It also puts more pressure on page allocator: we cannot re-use pages allocated for encrypted VMA to collapse page in unencrypted one or vice versa. I think for now it worth skipping encrypted VMAs. We can return to this topic later. Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> --- include/linux/mm.h | 7 +++++++ mm/khugepaged.c | 2 ++ 2 files changed, 9 insertions(+)