Huge page-table entries for TTM
Subsystems (8)
v6 cover Huge page-table entries for TTM
In order to reduce CPU usage [1] and in theory TLB misses this patchset enables huge- and giant page-table entries for TTM and TTM-enabled graphics drivers.
Patch 1 and 2 introduce a vma_is_special_huge() function to make the mm code take the same path as DAX when splitting huge- and giant page table entries, (which currently means zapping the page-table entry and rely on re-faulting).
Patch 3 makes the mm code split existing huge page-table entries on huge_fault fallbacks. Typically on COW or on buffer-objects that want write-notify. COW and write-notification is always done on the lowest page-table level. See the patch log message for additional considerations.
Patch 4 introduces functions to allow the graphics drivers to manipulate the caching- and encryption flags of huge page-table entries without ugly hacks.
Patch 5 implements the huge_fault handler in TTM.
This enables huge page-table entries, provided that the kernel is configured to support transhuge pages, either by default or using madvise(). However, they are unlikely to be inserted unless the kernel buffer object pfns and user-space addresses align perfectly. There are various options here, but since buffer objects that reside in system pages typically start at huge page boundaries if they are backed by huge pages, we try to enforce buffer object starting pfns and user-space addresses to be huge page-size aligned if their size exceeds a huge page-size. If pud-size transhuge ("giant") pages are enabled by the arch, the same holds for those.
Patch 6 implements a specialized huge_fault handler for vmwgfx. The vmwgfx driver may perform dirty-tracking and needs some special code to handle that correctly.
Patch 7 implements a drm helper to align user-space addresses according to the above scheme, if possible.
Patch 8 implements a TTM range manager for vmwgfx that does the same for graphics IO memory. This may later be reused by other graphics drivers if necessary.
Patch 9 finally hooks up the helpers of patch 7 and 8 to the vmwgfx driver. A similar change is needed for graphics drivers that want a reasonable likelyhood of actually using huge page-table entries.
If a buffer object size is not huge-page or giant-page aligned, its size will NOT be inflated by this patchset. This means that the buffer object tail will use smaller size page-table entries and thus no memory overhead occurs. Drivers that want to pay the memory overhead price need to implement their own scheme to inflate buffer-object sizes.
PMD size huge page-table-entries have been tested with vmwgfx and found to work well both with system memory backed and IO memory backed buffer objects.
PUD size giant page-table-entries have seen limited (fault and COW) testing using a modified kernel (to support 1GB page allocations) and a fake vmwgfx TTM memory type. The vmwgfx driver does otherwise not support 1GB-size IO memory resources.
Comments and suggestions welcome.
Thomas
Changes since RFC:
* Check for buffer objects present in contigous IO Memory (Christian König)
* Rebased on the vmwgfx emulated coherent memory functionality. That rebase adds patch 5.
Changes since v1:
* Make the new TTM range manager vmwgfx-specific. (Christian König)
* Minor fixes for configs that don't support or only partially support transhuge pages.
Changes since v2:
* Minor coding style and doc fixes in patch 5/9 (Christian König)
* Patch 5/9 doesn't touch mm. Remove from the patch title. Changes since v3:
* Added reviews and acks
* Implemented ugly but generic ttm_pgprot_is_wrprotecting() instead of arch specific code.
Changes since v4:
* Added timings (Andrew Morton)
* Updated function documentation (Andrew Morton)
Changes since v6:
* Fix drm build error with !CONFIG_MMU
[1]
The below test program generates the following gnu time output when run on a vmwgfx-enabled kernel without the patch series:
4.78user 6.02system 0:10.91elapsed 99%CPU (0avgtext+0avgdata 1624maxresident)k 0inputs+0outputs (0major+640077minor)pagefaults 0swaps
and with the patch series:
1.71user 3.60system 0:05.40elapsed 98%CPU (0avgtext+0avgdata 1656maxresident)k 0inputs+0outputs (0major+20079minor)pagefaults 0swaps
A consistent number of reduced graphics page-faults can be seen with normal graphics applications, but due to the aggressive buffer object caching in vmwgfx user-space drivers the CPU time reduction is within the error marginal.
#include <unistd.h>
#include <string.h>
#include <sys/mman.h>
#include <xf86drm.h>
static void checkerr(int ret, const char *name)
{
if (ret < 0) {
perror(name);
exit(-1); }
}
int main(int agc, const char *argv[])
{
struct drm_mode_create_dumb c_arg = {0};
struct drm_mode_map_dumb m_arg = {0};
struct drm_mode_destroy_dumb d_arg = {0};
int ret, i, fd;
void *map;
fd = open("/dev/dri/card0", O_RDWR);
checkerr(fd, argv[0]);
for (i = 0; i < 10000; ++i) {
c_arg.bpp = 32;
c_arg.width = 1024;
c_arg.height = 1024;
ret = drmIoctl(fd, DRM_IOCTL_MODE_CREATE_DUMB, &c_arg);
checkerr(fd, argv[0]);
m_arg.handle = c_arg.handle;
ret = drmIoctl(fd, DRM_IOCTL_MODE_MAP_DUMB, &m_arg);
checkerr(fd, argv[0]);
map = mmap(NULL, c_arg.size, PROT_READ | PROT_WRITE, MAP_SHARED, fd,
m_arg.offset);
checkerr(map == MAP_FAILED ? -1 : 0, argv[0]);
(void) madvise((void *) map, c_arg.size, MADV_HUGEPAGE);
memset(map, 0x67, c_arg.size);
munmap(map, c_arg.size);
d_arg.handle = c_arg.handle;
ret = drmIoctl(fd, DRM_IOCTL_MODE_DESTROY_DUMB, &d_arg);
checkerr(ret, argv[0]);
}
close(fd);
}PATCH v6 1/9 fs: Constify vma argument to vma_is_dax
From: Thomas Hellstrom <[email protected]>
The function is used by upcoming vma_is_special_huge() with which we want to use a const vma argument. Since for vma_is_dax() the vma argument is only dereferenced for reading, constify it.
--- include/linux/fs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/fs.h +1 -1
@@ -3391,7 +3391,7 @@ static inline bool io_is_direct(struct file *filp)return (filp->f_flags &O_DIRECT ) ||IS_DAX (filp->f_mapping->host); } -static inline bool vma_is_dax (struct vm_area_struct *vma) +static inline bool vma_is_dax (const struct vm_area_struct *vma) {return vma->vm_file &&IS_DAX (vma->vm_file->f_mapping->host); }
Signature · 6 lines
2.21.1 _______________________________________________ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
PATCH v6 2/9 mm: Introduce vma_is_special_huge
In reply to Thomas Hellström (VMware)From: Thomas Hellstrom <[email protected]>
For VM_PFNMAP and VM_MIXEDMAP vmas that want to support transhuge pages and -page table entries, introduce vma_is_special_huge() that takes the same codepaths as vma_is_dax().
The use of "special" follows the definition in memory.c, vm_normal_page():
"Special" mappings do not wish to be associated with a "struct page" (either it doesn't exist, or it exists but they don't want to touch it)
For PAGE_SIZE pages, "special" is determined per page table entry to be able to deal with COW pages. But since we don't have huge COW pages, we can classify a vma as either "special huge" or "normal huge".
--- include/linux/mm.h | 17 +++++++++++++++++ mm/huge_memory.c | 6 +++--- 2 files changed, 20 insertions(+), 3 deletions(-)
include/linux/mm.h +17 -0
@@ -2863,6 +2863,23 @@ extern long copy_huge_page_from_user(struct page *dst_page,const void __user *usr_src, unsigned int pages_per_huge_page, bool allow_pagefault); + +/** +* vma_is_special_huge - Are transhuge page-table entries considered special? +* @vma: Pointer to the struct vm_area_struct to consider +* +* Whether transhuge page-table entries are considered "special" following +* the definition in vm_normal_page(). +* +* Return: true if transhuge page-table entries should be considered special, +* false otherwise. +*/ +static inline bool vma_is_special_huge (const struct vm_area_struct *vma) +{ +return vma_is_dax (vma) || (vma->vm_file && + (vma->vm_flags & (VM_PFNMAP |VM_MIXEDMAP ))); +} +#endif /* CONFIG_TRANSPARENT_HUGEPAGE || CONFIG_HUGETLBFS */ #ifdef CONFIG_DEBUG_PAGEALLOC
mm/huge_memory.c +3 -3
@@ -1802,7 +1802,7 @@ int zap_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma, orig_pmd =pmdp_huge_get_and_clear_full (tlb->mm, addr, pmd, tlb->fullmm);tlb_remove_pmd_tlb_entry (tlb, pmd, addr); -if (vma_is_dax (vma)) { +if (vma_is_special_huge (vma)) {if (arch_needs_pgtable_deposit ())zap_deposited_table (tlb->mm, pmd);spin_unlock (ptl);
@@ -2066,7 +2066,7 @@ int zap_huge_pud(struct mmu_gather *tlb, struct vm_area_struct *vma,*/ pudp_huge_get_and_clear_full (tlb->mm, addr, pud, tlb->fullmm);tlb_remove_pud_tlb_entry (tlb, pud, addr); -if (vma_is_dax (vma)) { +if (vma_is_special_huge (vma)) {spin_unlock (ptl);/* No zero page support yet */ }else {
@@ -2175,7 +2175,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd,*/ if (arch_needs_pgtable_deposit ())zap_deposited_table (mm, pmd); -if (vma_is_dax (vma)) +if (vma_is_special_huge (vma))return ; page =pmd_page (_pmd);if (!PageDirty (page) &&pmd_dirty (_pmd))
Signature · 1 line
2.21.1
PATCH v6 3/9 mm: Split huge pages on write-notify or COW
In reply to Thomas Hellström (VMware)From: Thomas Hellstrom <[email protected]>
The functions wp_huge_pmd() and wp_huge_pud() currently relies on the huge_fault() callback to split huge page table entries if needed. However for module users that requires export of the split_huge_xxx() functionality which may be undesired. Instead split pre-existing huge page-table entries on VM_FAULT_FALLBACK return.
We currently only do COW and write-notify on the PTE level, so if the huge_fault() handler returns VM_FAULT_FALLBACK on wp faults, split the huge pages and page-table entries. Also do this for huge PUDs if there is no huge_fault() handler and the vma is not anonymous, similar to how it's done for PMDs.
Note that fs/dax.c still does the splitting in the huge_fault() handler, but as huge_fault() A follow-up patch can remove the dax.c split_huge_pmd() if needed.
--- mm/memory.c | 27 +++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-)
mm/memory.c +19 -8
@@ -3932,11 +3932,14 @@ static inline vm_fault_t wp_huge_pmd(struct vm_fault *vmf, pmd_t orig_pmd) {if (vma_is_anonymous (vmf->vma))return do_huge_pmd_wp_page (vmf, orig_pmd); -if (vmf->vma->vm_ops->huge_fault) -return vmf->vma->vm_ops->huge_fault (vmf,PE_SIZE_PMD ); +if (vmf->vma->vm_ops->huge_fault) { +vm_fault_t ret = vmf->vma->vm_ops->huge_fault (vmf,PE_SIZE_PMD ); -/* COW handled on pte level: split pmd */ -VM_BUG_ON_VMA (vmf->vma->vm_flags &VM_SHARED , vmf->vma); +if (!(ret &VM_FAULT_FALLBACK )) +return ret; + } + +/* COW or write-notify handled on pte level: split pmd. */ __split_huge_pmd (vmf->vma, vmf->pmd, vmf->address, false,NULL );return VM_FAULT_FALLBACK ;
@@ -3949,12 +3952,20 @@ static inline bool vma_is_accessible(struct vm_area_struct *vma)static vm_fault_t create_huge_pud (struct vm_fault *vmf) { -#ifdef CONFIG_TRANSPARENT_HUGEPAGE +#if defined(CONFIG_TRANSPARENT_HUGEPAGE ) && \ + defined(CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD )/* No support for anonymous transparent PUD pages yet */ if (vma_is_anonymous (vmf->vma)) -return VM_FAULT_FALLBACK ; -if (vmf->vma->vm_ops->huge_fault) -return vmf->vma->vm_ops->huge_fault (vmf,PE_SIZE_PUD ); + goto split; +if (vmf->vma->vm_ops->huge_fault) { +vm_fault_t ret = vmf->vma->vm_ops->huge_fault (vmf,PE_SIZE_PUD ); + +if (!(ret &VM_FAULT_FALLBACK )) +return ret; + } +split: +/* COW or write-notify not handled on PUD level: split pud.*/ +__split_huge_pud (vmf->vma, vmf->pud, vmf->address);#endif /* CONFIG_TRANSPARENT_HUGEPAGE */ return VM_FAULT_FALLBACK ; }
Signature · 1 line
2.21.1
PATCH v6 4/9 mm: Add vmf_insert_pfn_xxx_prot() for huge page-table entries
In reply to Thomas Hellström (VMware)From: Thomas Hellstrom <[email protected]>
For graphics drivers needing to modify the page-protection, add huge page-table entries counterparts to vmf_insert_pfn_prot().
--- include/linux/huge_mm.h | 41 +++++++++++++++++++++++++++++++++++++++-- mm/huge_memory.c | 38 ++++++++++++++++++++++++++++++++------ 2 files changed, 71 insertions(+), 8 deletions(-)
include/linux/huge_mm.h +39 -2
@@ -47,8 +47,45 @@ extern bool move_huge_pmd(struct vm_area_struct *vma, unsigned long old_addr,extern int change_huge_pmd (struct vm_area_struct *vma,pmd_t *pmd,unsigned long addr,pgprot_t newprot,int prot_numa); -vm_fault_t vmf_insert_pfn_pmd (struct vm_fault *vmf,pfn_t pfn,bool write); -vm_fault_t vmf_insert_pfn_pud (struct vm_fault *vmf,pfn_t pfn,bool write); +vm_fault_t vmf_insert_pfn_pmd_prot (struct vm_fault *vmf,pfn_t pfn, +pgprot_t pgprot,bool write); + +/** +* vmf_insert_pfn_pmd - insert a pmd size pfn +* @vmf: Structure describing the fault +* @pfn: pfn to insert +* @pgprot: page protection to use +* @write: whether it's a write fault +* +* Insert a pmd size pfn. See vmf_insert_pfn() for additional info. +* +* Return: vm_fault_t value. +*/ +static inline vm_fault_t vmf_insert_pfn_pmd (struct vm_fault *vmf,pfn_t pfn, +bool write) +{ +return vmf_insert_pfn_pmd_prot (vmf, pfn, vmf->vma->vm_page_prot, write); +} +vm_fault_t vmf_insert_pfn_pud_prot (struct vm_fault *vmf,pfn_t pfn, +pgprot_t pgprot,bool write); + +/** +* vmf_insert_pfn_pud - insert a pud size pfn +* @vmf: Structure describing the fault +* @pfn: pfn to insert +* @pgprot: page protection to use +* @write: whether it's a write fault +* +* Insert a pud size pfn. See vmf_insert_pfn() for additional info. +* +* Return: vm_fault_t value. +*/ +static inline vm_fault_t vmf_insert_pfn_pud (struct vm_fault *vmf,pfn_t pfn, +bool write) +{ +return vmf_insert_pfn_pud_prot (vmf, pfn, vmf->vma->vm_page_prot, write); +} +enum transparent_hugepage_flag {TRANSPARENT_HUGEPAGE_FLAG ,TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG ,
mm/huge_memory.c +32 -6
@@ -824,11 +824,24 @@ static void insert_pfn_pmd(struct vm_area_struct *vma, unsigned long addr,pte_free (mm, pgtable); } -vm_fault_t vmf_insert_pfn_pmd (struct vm_fault *vmf,pfn_t pfn,bool write) +/** +* vmf_insert_pfn_pmd_prot - insert a pmd size pfn +* @vmf: Structure describing the fault +* @pfn: pfn to insert +* @pgprot: page protection to use +* @write: whether it's a write fault +* +* Insert a pmd size pfn. See vmf_insert_pfn() for additional info and +* also consult the vmf_insert_mixed_prot() documentation when +* @pgprot != @vmf->vma->vm_page_prot. +* +* Return: vm_fault_t value. +*/ +vm_fault_t vmf_insert_pfn_pmd_prot (struct vm_fault *vmf,pfn_t pfn, +pgprot_t pgprot,bool write) {unsigned long addr = vmf->address &PMD_MASK ;struct vm_area_struct *vma = vmf->vma; -pgprot_t pgprot = vma->vm_page_prot;pgtable_t pgtable =NULL ;/*
@@ -856,7 +869,7 @@ vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write)insert_pfn_pmd (vma, addr, vmf->pmd, pfn, pgprot, write, pgtable);return VM_FAULT_NOPAGE ; } -EXPORT_SYMBOL_GPL (vmf_insert_pfn_pmd); +EXPORT_SYMBOL_GPL (vmf_insert_pfn_pmd_prot);#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD static pud_t maybe_pud_mkwrite (pud_t pud,struct vm_area_struct *vma)
@@ -902,11 +915,24 @@ static void insert_pfn_pud(struct vm_area_struct *vma, unsigned long addr,spin_unlock (ptl); } -vm_fault_t vmf_insert_pfn_pud (struct vm_fault *vmf,pfn_t pfn,bool write) +/** +* vmf_insert_pfn_pud_prot - insert a pud size pfn +* @vmf: Structure describing the fault +* @pfn: pfn to insert +* @pgprot: page protection to use +* @write: whether it's a write fault +* +* Insert a pud size pfn. See vmf_insert_pfn() for additional info and +* also consult the vmf_insert_mixed_prot() documentation when +* @pgprot != @vmf->vma->vm_page_prot. +* +* Return: vm_fault_t value. +*/ +vm_fault_t vmf_insert_pfn_pud_prot (struct vm_fault *vmf,pfn_t pfn, +pgprot_t pgprot,bool write) {unsigned long addr = vmf->address &PUD_MASK ;struct vm_area_struct *vma = vmf->vma; -pgprot_t pgprot = vma->vm_page_prot;/* * If we had pud_special, we could avoid all these restrictions,
@@ -927,7 +953,7 @@ vm_fault_t vmf_insert_pfn_pud(struct vm_fault *vmf, pfn_t pfn, bool write)insert_pfn_pud (vma, addr, vmf->pud, pfn, pgprot, write);return VM_FAULT_NOPAGE ; } -EXPORT_SYMBOL_GPL (vmf_insert_pfn_pud); +EXPORT_SYMBOL_GPL (vmf_insert_pfn_pud_prot);#endif /* CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD */ static void touch_pmd(struct vm_area_struct *vma, unsigned long addr,
Signature · 6 lines
2.21.1 _______________________________________________ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
PATCH v6 5/9 drm/ttm, drm/vmwgfx: Support huge TTM pagefaults
In reply to Thomas Hellström (VMware)From: Thomas Hellstrom <[email protected]>
Support huge (PMD-size and PUD-size) page-table entries by providing a huge_fault() callback.
We still support private mappings and write-notify by splitting the huge page-table entries on write-access.
Note that for huge page-faults to occur, either the kernel needs to be compiled with trans-huge-pages always enabled, or the kernel needs to be compiled with trans-huge-pages enabled using madvise, and the user-space app needs to call madvise() to enable trans-huge pages on a per-mapping basis.
Furthermore huge page-faults will not succeed unless buffer objects and user-space addresses are aligned on huge page size boundaries.
--- drivers/gpu/drm/ttm/ttm_bo_vm.c | 161 ++++++++++++++++++++- drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 2 +- include/drm/ttm/ttm_bo_api.h | 3 +- 3 files changed, 161 insertions(+), 5 deletions(-)
drivers/gpu/drm/ttm/ttm_bo_vm.c +158 -3
@@ -156,6 +156,89 @@ vm_fault_t ttm_bo_vm_reserve(struct ttm_buffer_object *bo, }EXPORT_SYMBOL (ttm_bo_vm_reserve); +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +/** +* ttm_bo_vm_insert_huge - Insert a pfn for PUD or PMD faults +* @vmf: Fault data +* @bo: The buffer object +* @page_offset: Page offset from bo start +* @fault_page_size: The size of the fault in pages. +* @pgprot: The page protections. +* Does additional checking whether it's possible to insert a PUD or PMD +* pfn and performs the insertion. +* +* Return: VM_FAULT_NOPAGE on successful insertion, VM_FAULT_FALLBACK if +* a huge fault was not possible, or on insertion error. +*/ +static vm_fault_t ttm_bo_vm_insert_huge (struct vm_fault *vmf, +struct ttm_buffer_object *bo, +pgoff_t page_offset, +pgoff_t fault_page_size, +pgprot_t pgprot) +{ +pgoff_t i; +vm_fault_t ret; +unsigned long pfn; +pfn_t pfnt; +struct ttm_tt *ttm = bo->ttm; +bool write = vmf->flags &FAULT_FLAG_WRITE ; + +/* Fault should not cross bo boundary. */ + page_offset &= ~(fault_page_size -1 ); +if (page_offset + fault_page_size > bo->num_pages) + goto out_fallback; + +if (bo->mem.bus.is_iomem) + pfn =ttm_bo_io_mem_pfn (bo, page_offset); +else + pfn =page_to_pfn (ttm->pages[page_offset]); + +/* pfn must be fault_page_size aligned. */ +if ((pfn & (fault_page_size -1 )) !=0 ) + goto out_fallback; + +/* Check that memory is contiguous. */ +if (!bo->mem.bus.is_iomem) { +for (i =1 ; i < fault_page_size; ++i) { +if (page_to_pfn (ttm->pages[page_offset + i]) != pfn + i) + goto out_fallback; + } + }else if (bo->bdev->driver->io_mem_pfn) { +for (i =1 ; i < fault_page_size; ++i) { +if (ttm_bo_io_mem_pfn (bo, page_offset + i) != pfn + i) + goto out_fallback; + } + } + + pfnt =__pfn_to_pfn_t (pfn,PFN_DEV ); +if (fault_page_size == (HPAGE_PMD_SIZE >>PAGE_SHIFT )) + ret =vmf_insert_pfn_pmd_prot (vmf, pfnt, pgprot, write); +#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD + else if (fault_page_size == (HPAGE_PUD_SIZE >> PAGE_SHIFT)) + ret =vmf_insert_pfn_pud_prot (vmf, pfnt, pgprot, write); +#endif + else + WARN_ON_ONCE(ret = VM_FAULT_FALLBACK); + +if (ret !=VM_FAULT_NOPAGE ) + goto out_fallback; + +return VM_FAULT_NOPAGE ; +out_fallback: +count_vm_event (THP_FAULT_FALLBACK ); +return VM_FAULT_FALLBACK ; +} +#else +static vm_fault_t ttm_bo_vm_insert_huge (struct vm_fault *vmf, +struct ttm_buffer_object *bo, +pgoff_t page_offset, +pgoff_t fault_page_size, +pgprot_t pgprot) +{ +return VM_FAULT_FALLBACK ; +} +#endif +/** * ttm_bo_vm_fault_reserved - TTM fault helper * @vmf: The struct vm_fault given as argument to the fault callback
@@ -163,6 +246,7 @@ EXPORT_SYMBOL(ttm_bo_vm_reserve);* @num_prefault: Maximum number of prefault pages. The caller may want to * specify this based on madvice settings and the size of the GPU object * backed by the memory. +* @fault_page_size: The size of the fault in pages. * * This function inserts one or more page table entries pointing to the * memory backing the buffer object, and then returns a return code
@@ -176,7 +260,8 @@ EXPORT_SYMBOL(ttm_bo_vm_reserve);*/ vm_fault_t ttm_bo_vm_fault_reserved (struct vm_fault *vmf,pgprot_t prot, -pgoff_t num_prefault) +pgoff_t num_prefault, +pgoff_t fault_page_size) {struct vm_area_struct *vma = vmf->vma;struct ttm_buffer_object *bo = vma->vm_private_data;
@@ -268,6 +353,13 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf, prot =pgprot_decrypted (prot); } +/* We don't prefault on huge faults. Yet. */ +if (IS_ENABLED (CONFIG_TRANSPARENT_HUGEPAGE ) && fault_page_size !=1 ) { + ret =ttm_bo_vm_insert_huge (vmf, bo, page_offset, + fault_page_size, prot); + goto out_io_unlock; + } +/* * Speculatively prefault a number of pages. Only error on * first page.
@@ -334,7 +426,7 @@ vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)return ret; prot = vma->vm_page_prot; - ret =ttm_bo_vm_fault_reserved (vmf, prot,TTM_BO_VM_NUM_PREFAULT ); + ret =ttm_bo_vm_fault_reserved (vmf, prot,TTM_BO_VM_NUM_PREFAULT ,1 );if (ret ==VM_FAULT_RETRY && !(vmf->flags &FAULT_FLAG_RETRY_NOWAIT ))return ret;
@@ -344,6 +436,66 @@ vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf) }EXPORT_SYMBOL (ttm_bo_vm_fault); +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +/** +* ttm_pgprot_is_wrprotecting - Is a page protection value write-protecting? +* @prot: The page protection value +* +* Return: true if @prot is write-protecting. false otherwise. +*/ +static bool ttm_pgprot_is_wrprotecting (pgprot_t prot) +{ +/* +* This is meant to say "pgprot_wrprotect(prot) == prot" in a generic +* way. Unfortunately there is no generic pgprot_wrprotect. +*/ +return pte_val (pte_wrprotect (__pte (pgprot_val (prot)))) == +pgprot_val (prot); +} + +static vm_fault_t ttm_bo_vm_huge_fault (struct vm_fault *vmf, +enum page_entry_size pe_size) +{ +struct vm_area_struct *vma = vmf->vma; +pgprot_t prot; +struct ttm_buffer_object *bo = vma->vm_private_data; +vm_fault_t ret; +pgoff_t fault_page_size =0 ; +bool write = vmf->flags &FAULT_FLAG_WRITE ; + +switch (pe_size) { +case PE_SIZE_PMD : + fault_page_size =HPAGE_PMD_SIZE >>PAGE_SHIFT ; +break ; +#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD +case PE_SIZE_PUD : + fault_page_size =HPAGE_PUD_SIZE >>PAGE_SHIFT ; +break ; +#endif +default : +WARN_ON_ONCE (1 ); +return VM_FAULT_FALLBACK ; + } + +/* Fallback on write dirty-tracking or COW */ +if (write &&ttm_pgprot_is_wrprotecting (vma->vm_page_prot)) +return VM_FAULT_FALLBACK ; + + ret =ttm_bo_vm_reserve (bo, vmf); +if (ret) +return ret; + + prot =vm_get_page_prot (vma->vm_flags); + ret =ttm_bo_vm_fault_reserved (vmf, prot,1 , fault_page_size); +if (ret ==VM_FAULT_RETRY && !(vmf->flags &FAULT_FLAG_RETRY_NOWAIT )) +return ret; + +dma_resv_unlock (bo->base.resv); + +return ret; +} +#endif +void ttm_bo_vm_open (struct vm_area_struct *vma) {struct ttm_buffer_object *bo = vma->vm_private_data;
@@ -445,7 +597,10 @@ static const struct vm_operations_struct ttm_bo_vm_ops = { .fault = ttm_bo_vm_fault, .open = ttm_bo_vm_open, .close = ttm_bo_vm_close, - .access = ttm_bo_vm_access + .access = ttm_bo_vm_access, +#ifdef CONFIG_TRANSPARENT_HUGEPAGE + .huge_fault = ttm_bo_vm_huge_fault, +#endif }; static struct ttm_buffer_object *ttm_bo_vm_lookup(struct ttm_bo_device *bdev,
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c +1 -1
@@ -477,7 +477,7 @@ vm_fault_t vmw_bo_vm_fault(struct vm_fault *vmf)else prot =vm_get_page_prot (vma->vm_flags); - ret =ttm_bo_vm_fault_reserved (vmf, prot, num_prefault); + ret =ttm_bo_vm_fault_reserved (vmf, prot, num_prefault,1 );if (ret ==VM_FAULT_RETRY && !(vmf->flags &FAULT_FLAG_RETRY_NOWAIT ))return ret;
include/drm/ttm/ttm_bo_api.h +2 -1
@@ -732,7 +732,8 @@ vm_fault_t ttm_bo_vm_reserve(struct ttm_buffer_object *bo,vm_fault_t ttm_bo_vm_fault_reserved (struct vm_fault *vmf,pgprot_t prot, -pgoff_t num_prefault); +pgoff_t num_prefault, +pgoff_t fault_page_size);vm_fault_t ttm_bo_vm_fault (struct vm_fault *vmf);
Signature · 1 line
2.21.1
PATCH v6 6/9 drm/vmwgfx: Support huge page faults
In reply to Thomas Hellström (VMware)From: Thomas Hellstrom <[email protected]>
With vmwgfx dirty-tracking we need a specialized huge_fault callback. Implement and hook it up.
--- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 4 ++ drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 74 +++++++++++++++++++++- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 5 +- 3 files changed, 81 insertions(+), 2 deletions(-)
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h +4 -0
@@ -1430,6 +1430,10 @@ void vmw_bo_dirty_unmap(struct vmw_buffer_object *vbo, pgoff_t start, pgoff_t end);vm_fault_t vmw_bo_vm_fault (struct vm_fault *vmf);vm_fault_t vmw_bo_vm_mkwrite (struct vm_fault *vmf); +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +vm_fault_t vmw_bo_vm_huge_fault (struct vm_fault *vmf, +enum page_entry_size pe_size); +#endif /** * VMW_DEBUG_KMS - Debug output for kernel mode-setting
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c +73 -1
83 lines not on this page · raw message
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c +4 -1
@@ -34,7 +34,10 @@ int vmw_mmap(struct file *filp, struct vm_area_struct *vma) .page_mkwrite = vmw_bo_vm_mkwrite, .fault = vmw_bo_vm_fault, .open = ttm_bo_vm_open, - .close = ttm_bo_vm_close + .close = ttm_bo_vm_close, +#ifdef CONFIG_TRANSPARENT_HUGEPAGE + .huge_fault = vmw_bo_vm_huge_fault, +#endif };struct drm_file *file_priv = filp->private_data;struct vmw_private *dev_priv =vmw_priv (file_priv->minor->dev);
Signature · 6 lines
2.21.1 _______________________________________________ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
PATCH v6 7/9 drm: Add a drm_get_unmapped_area() helper
In reply to Thomas Hellström (VMware)From: Thomas Hellstrom <[email protected]>
Unaligned virtual addresses makes it unlikely that huge page-table entries can be used.
So align virtual buffer object address huge page boundaries to the underlying physical address huge page boundaries taking buffer object sizes into account to determine when it might be possible to use huge page-table entries.
--- drivers/gpu/drm/drm_file.c | 140 +++++++++++++++++++++++++++++++++++++ include/drm/drm_file.h | 9 +++ 2 files changed, 149 insertions(+)
drivers/gpu/drm/drm_file.c +140 -0
@@ -48,6 +48,11 @@#include "drm_internal.h" #include "drm_legacy.h" +#ifdef CONFIG_MMU +#include <uapi/asm/mman.h> +#include <drm/drm_vma_manager.h> +#endif +/* from BKL pushdown */ DEFINE_MUTEX (drm_global_mutex);
@@ -796,3 +801,138 @@ struct file *mock_drm_getfile(struct drm_minor *minor, unsigned int flags)return file; }EXPORT_SYMBOL_FOR_TESTS_ONLY (mock_drm_getfile); + +#ifdef CONFIG_MMU +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +/* +* drm_addr_inflate() attempts to construct an aligned area by inflating +* the area size and skipping the unaligned start of the area. +* adapted from shmem_get_unmapped_area() +*/ +static unsigned long drm_addr_inflate (unsigned long addr, +unsigned long len, +unsigned long pgoff, +unsigned long flags, +unsigned long huge_size) +{ +unsigned long offset, inflated_len; +unsigned long inflated_addr; +unsigned long inflated_offset; + + offset = (pgoff <<PAGE_SHIFT ) & (huge_size -1 ); +if (offset && offset + len <2 * huge_size) +return addr; +if ((addr & (huge_size -1 )) == offset) +return addr; + + inflated_len = len + huge_size -PAGE_SIZE ; +if (inflated_len >TASK_SIZE ) +return addr; +if (inflated_len < len) +return addr; + + inflated_addr = current->mm->get_unmapped_area (NULL ,0 , inflated_len, +0 , flags); +if (IS_ERR_VALUE (inflated_addr)) +return addr; +if (inflated_addr & ~PAGE_MASK ) +return addr; + + inflated_offset = inflated_addr & (huge_size -1 ); + inflated_addr += offset - inflated_offset; +if (inflated_offset > offset) + inflated_addr += huge_size; + +if (inflated_addr >TASK_SIZE - len) +return addr; + +return inflated_addr; +} + +/** +* drm_get_unmapped_area() - Get an unused user-space virtual memory area +* suitable for huge page table entries. +* @file: The struct file representing the address space being mmap()'d. +* @uaddr: Start address suggested by user-space. +* @len: Length of the area. +* @pgoff: The page offset into the address space. +* @flags: mmap flags +* @mgr: The address space manager used by the drm driver. This argument can +* probably be removed at some point when all drivers use the same +* address space manager. +* +* This function attempts to find an unused user-space virtual memory area +* that can accommodate the size we want to map, and that is properly +* aligned to facilitate huge page table entries matching actual +* huge pages or huge page aligned memory in buffer objects. Buffer objects +* are assumed to start at huge page boundary pfns (io memory) or be +* populated by huge pages aligned to the start of the buffer object +* (system- or coherent memory). Adapted from shmem_get_unmapped_area. +* +* Return: aligned user-space address. +*/ +unsigned long drm_get_unmapped_area (struct file *file, +unsigned long uaddr,unsigned long len, +unsigned long pgoff,unsigned long flags, +struct drm_vma_offset_manager *mgr) +{ +unsigned long addr; +unsigned long inflated_addr; +struct drm_vma_offset_node *node; + +if (len >TASK_SIZE ) +return -ENOMEM ; + +/* +* @pgoff is the file page-offset the huge page boundaries of +* which typically aligns to physical address huge page boundaries. +* That's not true for DRM, however, where physical address huge +* page boundaries instead are aligned with the offset from +* buffer object start. So adjust @pgoff to be the offset from +* buffer object start. +*/ +drm_vma_offset_lock_lookup (mgr); + node =drm_vma_offset_lookup_locked (mgr, pgoff,1 ); +if (node) + pgoff -= node->vm_node.start; +drm_vma_offset_unlock_lookup (mgr); + + addr = current->mm->get_unmapped_area (file, uaddr, len, pgoff, flags); +if (IS_ERR_VALUE (addr)) +return addr; +if (addr & ~PAGE_MASK ) +return addr; +if (addr >TASK_SIZE - len) +return addr; + +if (len <HPAGE_PMD_SIZE ) +return addr; +if (flags &MAP_FIXED ) +return addr; +/* +* Our priority is to support MAP_SHARED mapped hugely; +* and support MAP_PRIVATE mapped hugely too, until it is COWed. +* But if caller specified an address hint, respect that as before. +*/ +if (uaddr) +return addr; + + inflated_addr =drm_addr_inflate (addr, len, pgoff, flags, +HPAGE_PMD_SIZE ); + +if (IS_ENABLED (CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD ) && + len >=HPAGE_PUD_SIZE ) + inflated_addr =drm_addr_inflate (inflated_addr, len, pgoff, + flags,HPAGE_PUD_SIZE ); +return inflated_addr; +} +#else /* CONFIG_TRANSPARENT_HUGEPAGE */ +unsigned long drm_get_unmapped_area (struct file *file, +unsigned long uaddr,unsigned long len, +unsigned long pgoff,unsigned long flags, +struct drm_vma_offset_manager *mgr) +{ +return current->mm->get_unmapped_area (file, uaddr, len, pgoff, flags); +} +#endif /* CONFIG_TRANSPARENT_HUGEPAGE */ +#endif /* CONFIG_MMU */
include/drm/drm_file.h +9 -0
@@ -390,4 +390,13 @@ void drm_send_event(struct drm_device *dev, struct drm_pending_event *e);struct file *mock_drm_getfile (struct drm_minor *minor,unsigned int flags); +#ifdef CONFIG_MMU +struct drm_vma_offset_manager ; +unsigned long drm_get_unmapped_area (struct file *file, +unsigned long uaddr,unsigned long len, +unsigned long pgoff,unsigned long flags, +struct drm_vma_offset_manager *mgr); +#endif /* CONFIG_MMU */ + +#endif /* _DRM_FILE_H_ */
Signature · 1 line
2.21.1
PATCH v6 8/9 drm/vmwgfx: Introduce a huge page aligning TTM range manager
In reply to Thomas Hellström (VMware)From: Thomas Hellstrom <[email protected]>
Using huge page-table entries requires that the physical address of the start of a buffer object is huge page size aligned.
Make a special version of the TTM range manager that accomplishes this, but falls back to a smaller page size alignment (PUD->PMD, PMD->NORMAL) to avoid eviction.
If other drivers want to use it in the future, it can be made a TTM generic helper. Note that drivers can force eviction for a certain alignment by assigning the TTM GPU alignment correspondingly.
--- drivers/gpu/drm/vmwgfx/Makefile | 1 + drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 7 ++ drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 166 ++++++++++++++++++++++++++++ 3 files changed, 174 insertions(+) create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_thp.c
drivers/gpu/drm/vmwgfx/Makefile +1 -0
@@ -11,4 +11,5 @@ vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o vmwgfx_drv.o \ vmwgfx_validation.o vmwgfx_page_dirty.o \ ttm_object.o ttm_lock.o +vmwgfx-$(CONFIG_TRANSPARENT_HUGEPAGE) += vmwgfx_thp.o obj-$(CONFIG_DRM_VMWGFX) := vmwgfx.o
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h +7 -0
@@ -1435,6 +1435,13 @@ vm_fault_t vmw_bo_vm_huge_fault(struct vm_fault *vmf, enum page_entry_size pe_size);#endif +/* Transparent hugepage support - vmwgfx_thp.c */ +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +extern const struct ttm_mem_type_manager_func vmw_thp_func; +#else +#define vmw_thp_func ttm_bo_manager_func +#endif +/** * VMW_DEBUG_KMS - Debug output for kernel mode-setting *
drivers/gpu/drm/vmwgfx/vmwgfx_thp.c new file +166 -0
166 lines not on this page · raw message
Signature · 1 line
2.21.1
PATCH v6 9/9 drm/vmwgfx: Hook up the helpers to align buffer objects
In reply to Thomas Hellström (VMware)From: Thomas Hellstrom <[email protected]>
Start using the helpers that align buffer object user-space addresses and buffer object vram addresses to huge page boundaries.
This is to improve the chances of allowing huge page-table entries.
--- drivers/gpu/drm/drm_file.c | 1 + drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 13 +++++++++++++ drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 + drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 +- 4 files changed, 16 insertions(+), 1 deletion(-)
drivers/gpu/drm/drm_file.c +1 -0
@@ -935,4 +935,5 @@ unsigned long drm_get_unmapped_area(struct file *file,return current->mm->get_unmapped_area (file, uaddr, len, pgoff, flags); }#endif /* CONFIG_TRANSPARENT_HUGEPAGE */ +EXPORT_SYMBOL_GPL (drm_get_unmapped_area);#endif /* CONFIG_MMU */
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c +13 -0
@@ -1223,6 +1223,18 @@ static void vmw_remove(struct pci_dev *pdev)pci_disable_device (pdev); } +static unsigned long +vmw_get_unmapped_area (struct file *file,unsigned long uaddr, +unsigned long len,unsigned long pgoff, +unsigned long flags) +{ +struct drm_file *file_priv = file->private_data; +struct vmw_private *dev_priv =vmw_priv (file_priv->minor->dev); + +return drm_get_unmapped_area (file, uaddr, len, pgoff, flags, + &dev_priv->vma_manager); +} +static int vmwgfx_pm_notifier (struct notifier_block *nb,unsigned long val,void *ptr) {
@@ -1394,6 +1406,7 @@ static const struct file_operations vmwgfx_driver_fops = { .compat_ioctl = vmw_compat_ioctl, #endif .llseek = noop_llseek, + .get_unmapped_area = vmw_get_unmapped_area, }; static struct drm_driver driver = {
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h +1 -0
@@ -929,6 +929,7 @@ extern int vmw_mmap(struct file *filp, struct vm_area_struct *vma);extern void vmw_validation_mem_init_ttm (struct vmw_private *dev_priv,size_t gran); +/** * TTM buffer object driver - vmwgfx_ttm_buffer.c */
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c +1 -1
@@ -754,7 +754,7 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,break ;case TTM_PL_VRAM :/* "On-card" video ram */ - man->func = &ttm_bo_manager_func; + man->func = &vmw_thp_func; man->gpu_offset =0 ; man->flags =TTM_MEMTYPE_FLAG_FIXED |TTM_MEMTYPE_FLAG_MAPPABLE ; man->available_caching =TTM_PL_FLAG_CACHED ;
Signature · 1 line
2.21.1
Ack to merge through DRM? WAS [PATCH v6 0/9] Huge page-table entries for TTM
In reply to Thomas Hellström (VMware)Quoted 157 lines · Thomas Hellström (VMware)
In order to reduce CPU usage [1] and in theory TLB misses this patchset enables huge- and giant page-table entries for TTM and TTM-enabled graphics drivers.
Patch 1 and 2 introduce a
vma_is_special_huge()function to make the mm code take the same path as DAX when splitting huge- and giant page table entries, (which currently means zapping the page-table entry and rely on re-faulting).Patch 3 makes the mm code split existing huge page-table entries on
huge_faultfallbacks. Typically on COW or on buffer-objects that want write-notify. COW and write-notification is always done on the lowest page-table level. See the patch log message for additional considerations.Patch 4 introduces functions to allow the graphics drivers to manipulate the caching- and encryption flags of huge page-table entries without ugly hacks.
Patch 5 implements the
huge_faulthandler in TTM.
This enables huge page-table entries, provided that the kernel is configured to support transhuge pages, either by default or usingmadvise(). However, they are unlikely to be inserted unless the kernel buffer object pfns and user-space addresses align perfectly. There are various options here, but since buffer objects that reside in system pages typically start at huge page boundaries if they are backed by huge pages, we try to enforce buffer object starting pfns and user-space addresses to be huge page-size aligned if their size exceeds a huge page-size. If pud-size transhuge ("giant") pages are enabled by the arch, the same holds for those.Patch 6 implements a specialized
huge_faulthandler for vmwgfx. The vmwgfx driver may perform dirty-tracking and needs some special code to handle that correctly.Patch 7 implements a drm helper to align user-space addresses according to the above scheme, if possible.
Patch 8 implements a TTM range manager for vmwgfx that does the same for graphics IO memory. This may later be reused by other graphics drivers if necessary.
Patch 9 finally hooks up the helpers of patch 7 and 8 to the vmwgfx driver. A similar change is needed for graphics drivers that want a reasonable likelyhood of actually using huge page-table entries.
If a buffer object size is not huge-page or giant-page aligned, its size will NOT be inflated by this patchset. This means that the buffer object tail will use smaller size page-table entries and thus no memory overhead occurs. Drivers that want to pay the memory overhead price need to implement their own scheme to inflate buffer-object sizes.
PMD size huge page-table-entries have been tested with vmwgfx and found to work well both with system memory backed and IO memory backed buffer objects.
PUD size giant page-table-entries have seen limited (fault and COW) testing using a modified kernel (to support 1GB page allocations) and a fake vmwgfx TTM memory type. The vmwgfx driver does otherwise not support 1GB-size IO memory resources.
Comments and suggestions welcome.
ThomasChanges since RFC:
* Check for buffer objects present in contigous IO Memory (Christian König)
* Rebased on the vmwgfx emulated coherent memory functionality. That rebase adds patch 5.
Changes since v1:
* Make the new TTM range manager vmwgfx-specific. (Christian König)
* Minor fixes for configs that don't support or only partially support transhuge pages.
Changes since v2:
* Minor coding style and doc fixes in patch 5/9 (Christian König)
* Patch 5/9 doesn't touch mm. Remove from the patch title. Changes since v3:
* Added reviews and acks
* Implemented ugly but genericttm_pgprot_is_wrprotecting()instead of arch specific code.
Changes since v4:
* Added timings (Andrew Morton)
* Updated function documentation (Andrew Morton)
Changes since v6:
* Fix drm build error with !CONFIG_MMU[1]
The below test program generates the following gnu time output when run on a vmwgfx-enabled kernel without the patch series:4.78user 6.02system 0:10.91elapsed 99%CPU (0avgtext+0avgdata 1624maxresident)k 0inputs+0outputs (0major+640077minor)pagefaults 0swaps
and with the patch series:
1.71user 3.60system 0:05.40elapsed 98%CPU (0avgtext+0avgdata 1656maxresident)k 0inputs+0outputs (0major+20079minor)pagefaults 0swaps
A consistent number of reduced graphics page-faults can be seen with normal graphics applications, but due to the aggressive buffer object caching in vmwgfx user-space drivers the CPU time reduction is within the error marginal.
#include <
unistd.h>
#include <string.h>
#include <sys/mman.h>
#include <xf86drm.h>static void
checkerr(int ret, const char *name){ if (ret < 0) { perror(name); exit(-1); } }int
main(int agc, const char *argv[]){ struct drm_mode_create_dumb c_arg = {0}; struct drm_mode_map_dumb m_arg = {0}; struct drm_mode_destroy_dumb d_arg = {0}; int ret, i, fd; void *map; fd = open("/dev/dri/card0", O_RDWR); checkerr(fd, argv[0]); for (i = 0; i < 10000; ++i) { c_arg.bpp = 32; c_arg.width = 1024; c_arg.height = 1024; ret = drmIoctl(fd, DRM_IOCTL_MODE_CREATE_DUMB, &c_arg); checkerr(fd, argv[0]); m_arg.handle = c_arg.handle; ret = drmIoctl(fd, DRM_IOCTL_MODE_MAP_DUMB, &m_arg); checkerr(fd, argv[0]); map = mmap(NULL, c_arg.size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, m_arg.offset); checkerr(map == MAP_FAILED ? -1 : 0, argv[0]); (void) madvise((void *) map, c_arg.size, MADV_HUGEPAGE); memset(map, 0x67, c_arg.size); munmap(map, c_arg.size); d_arg.handle = c_arg.handle; ret = drmIoctl(fd, DRM_IOCTL_MODE_DESTROY_DUMB, &d_arg); checkerr(ret, argv[0]); } close(fd); }Cc Andrew Morton <[email protected]>Cc Michal Hocko <[email protected]>Cc "Matthew Wilcox (Oracle)" <[email protected]>Cc "Kirill A. Shutemov" <[email protected]>Cc Ralph Campbell <[email protected]>Cc "Jérôme Glisse" <[email protected]>Cc "Christian König" <[email protected]>Cc Dan Williams <[email protected]>
Quoted 4 lines
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Andrew, would it be possible to have an ack for merge using a DRM tree for the -mm patches?
Thanks,
Thomas
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Andrew Morton
maintainerRe: Ack to merge through DRM? WAS [PATCH v6 0/9] Huge page-table entries for TTM
Quoted 7 lines · On Mon, 16 Mar 2020 13:32:08 +0100 Thomas Hellström (VMware)…
Quoted 4 lines
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-develAndrew, would it be possible to have an ack for merge using a DRM tree for the -mm patches?
Yes, please do. It's all pretty straightforward addition of new functionality which won't affect existing code.
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Ack to merge through DRM? WAS [PATCH v6 0/9] Huge page-table entries for TTM
Quoted 10 lines · Andrew Morton
Quoted 6 lines · On Mon, 16 Mar 2020 13:32:08 +0100 Thomas Hellström (VMware)…
Quoted 4 lines
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-develAndrew, would it be possible to have an ack for merge using a DRM tree for the -mm patches?
Yes, please do. It's all pretty straightforward addition of new functionality which won't affect existing code.
Thanks Andrew. Can I add your Acked-by: To the mm patches for Linus' reference?
Thanks,
Thomas
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Andrew Morton
maintainerRe: Ack to merge through DRM? WAS [PATCH v6 0/9] Huge page-table entries for TTM
Quoted 7 lines · On Thu, 19 Mar 2020 11:20:44 +0100 Thomas Hellström (VMware)…
Quoted 6 lines · Andrew Morton
Quoted 4 lines · On Mon, 16 Mar 2020 13:32:08 +0100 Thomas Hellström (VMware)…
Quoted 4 lines
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
Andrew, would it be possible to have an ack for merge using a DRM tree for the -mm patches?
Yes, please do. It's all pretty straightforward addition of new functionality which won't affect existing code.
Thanks Andrew. Can I add your Acked-by: To the mm patches for Linus' reference?
Please do.
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Separate pull request? WAS: [PATCH v6 0/9] Huge page-table entries for TTM
In reply to Thomas Hellström (VMware)Quoted 157 lines · Thomas Hellström (VMware)
In order to reduce CPU usage [1] and in theory TLB misses this patchset enables huge- and giant page-table entries for TTM and TTM-enabled graphics drivers.
Patch 1 and 2 introduce a
vma_is_special_huge()function to make the mm code take the same path as DAX when splitting huge- and giant page table entries, (which currently means zapping the page-table entry and rely on re-faulting).Patch 3 makes the mm code split existing huge page-table entries on
huge_faultfallbacks. Typically on COW or on buffer-objects that want write-notify. COW and write-notification is always done on the lowest page-table level. See the patch log message for additional considerations.Patch 4 introduces functions to allow the graphics drivers to manipulate the caching- and encryption flags of huge page-table entries without ugly hacks.
Patch 5 implements the
huge_faulthandler in TTM.
This enables huge page-table entries, provided that the kernel is configured to support transhuge pages, either by default or usingmadvise(). However, they are unlikely to be inserted unless the kernel buffer object pfns and user-space addresses align perfectly. There are various options here, but since buffer objects that reside in system pages typically start at huge page boundaries if they are backed by huge pages, we try to enforce buffer object starting pfns and user-space addresses to be huge page-size aligned if their size exceeds a huge page-size. If pud-size transhuge ("giant") pages are enabled by the arch, the same holds for those.Patch 6 implements a specialized
huge_faulthandler for vmwgfx. The vmwgfx driver may perform dirty-tracking and needs some special code to handle that correctly.Patch 7 implements a drm helper to align user-space addresses according to the above scheme, if possible.
Patch 8 implements a TTM range manager for vmwgfx that does the same for graphics IO memory. This may later be reused by other graphics drivers if necessary.
Patch 9 finally hooks up the helpers of patch 7 and 8 to the vmwgfx driver. A similar change is needed for graphics drivers that want a reasonable likelyhood of actually using huge page-table entries.
If a buffer object size is not huge-page or giant-page aligned, its size will NOT be inflated by this patchset. This means that the buffer object tail will use smaller size page-table entries and thus no memory overhead occurs. Drivers that want to pay the memory overhead price need to implement their own scheme to inflate buffer-object sizes.
PMD size huge page-table-entries have been tested with vmwgfx and found to work well both with system memory backed and IO memory backed buffer objects.
PUD size giant page-table-entries have seen limited (fault and COW) testing using a modified kernel (to support 1GB page allocations) and a fake vmwgfx TTM memory type. The vmwgfx driver does otherwise not support 1GB-size IO memory resources.
Comments and suggestions welcome.
ThomasChanges since RFC:
* Check for buffer objects present in contigous IO Memory (Christian König)
* Rebased on the vmwgfx emulated coherent memory functionality. That rebase adds patch 5.
Changes since v1:
* Make the new TTM range manager vmwgfx-specific. (Christian König)
* Minor fixes for configs that don't support or only partially support transhuge pages.
Changes since v2:
* Minor coding style and doc fixes in patch 5/9 (Christian König)
* Patch 5/9 doesn't touch mm. Remove from the patch title. Changes since v3:
* Added reviews and acks
* Implemented ugly but genericttm_pgprot_is_wrprotecting()instead of arch specific code.
Changes since v4:
* Added timings (Andrew Morton)
* Updated function documentation (Andrew Morton)
Changes since v6:
* Fix drm build error with !CONFIG_MMU[1]
The below test program generates the following gnu time output when run on a vmwgfx-enabled kernel without the patch series:4.78user 6.02system 0:10.91elapsed 99%CPU (0avgtext+0avgdata 1624maxresident)k 0inputs+0outputs (0major+640077minor)pagefaults 0swaps
and with the patch series:
1.71user 3.60system 0:05.40elapsed 98%CPU (0avgtext+0avgdata 1656maxresident)k 0inputs+0outputs (0major+20079minor)pagefaults 0swaps
A consistent number of reduced graphics page-faults can be seen with normal graphics applications, but due to the aggressive buffer object caching in vmwgfx user-space drivers the CPU time reduction is within the error marginal.
#include <
unistd.h>
#include <string.h>
#include <sys/mman.h>
#include <xf86drm.h>static void
checkerr(int ret, const char *name){ if (ret < 0) { perror(name); exit(-1); } }int
main(int agc, const char *argv[]){ struct drm_mode_create_dumb c_arg = {0}; struct drm_mode_map_dumb m_arg = {0}; struct drm_mode_destroy_dumb d_arg = {0}; int ret, i, fd; void *map; fd = open("/dev/dri/card0", O_RDWR); checkerr(fd, argv[0]); for (i = 0; i < 10000; ++i) { c_arg.bpp = 32; c_arg.width = 1024; c_arg.height = 1024; ret = drmIoctl(fd, DRM_IOCTL_MODE_CREATE_DUMB, &c_arg); checkerr(fd, argv[0]); m_arg.handle = c_arg.handle; ret = drmIoctl(fd, DRM_IOCTL_MODE_MAP_DUMB, &m_arg); checkerr(fd, argv[0]); map = mmap(NULL, c_arg.size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, m_arg.offset); checkerr(map == MAP_FAILED ? -1 : 0, argv[0]); (void) madvise((void *) map, c_arg.size, MADV_HUGEPAGE); memset(map, 0x67, c_arg.size); munmap(map, c_arg.size); d_arg.handle = c_arg.handle; ret = drmIoctl(fd, DRM_IOCTL_MODE_DESTROY_DUMB, &d_arg); checkerr(ret, argv[0]); } close(fd); }Cc Andrew Morton <[email protected]>Cc Michal Hocko <[email protected]>Cc "Matthew Wilcox (Oracle)" <[email protected]>Cc "Kirill A. Shutemov" <[email protected]>Cc Ralph Campbell <[email protected]>Cc "Jérôme Glisse" <[email protected]>Cc "Christian König" <[email protected]>Cc Dan Williams <[email protected]>
Quoted 4 lines
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi, Christian,
I think this should be OK to merge now. Is it OK if I ask Dave to pull this separately?
Thanks,
Thomas
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Separate pull request? WAS: [PATCH v6 0/9] Huge page-table entries for TTM
Yeah, sure go ahead.
It's just that I am out of office because of COVID-19 and won't be able to help if it goes up in flames :)
Cheers,
Christian
Am 24.03.2020 11:03 schrieb "Thomas Hellström (VMware)" <[email protected]>:
Quoted 157 lines · Thomas Hellström (VMware)
In order to reduce CPU usage [1] and in theory TLB misses this patchset enables huge- and giant page-table entries for TTM and TTM-enabled graphics drivers.
Patch 1 and 2 introduce a
vma_is_special_huge()function to make the mm code take the same path as DAX when splitting huge- and giant page table entries, (which currently means zapping the page-table entry and rely on re-faulting).Patch 3 makes the mm code split existing huge page-table entries on
huge_faultfallbacks. Typically on COW or on buffer-objects that want write-notify. COW and write-notification is always done on the lowest page-table level. See the patch log message for additional considerations.Patch 4 introduces functions to allow the graphics drivers to manipulate the caching- and encryption flags of huge page-table entries without ugly hacks.
Patch 5 implements the
huge_faulthandler in TTM.
This enables huge page-table entries, provided that the kernel is configured to support transhuge pages, either by default or usingmadvise(). However, they are unlikely to be inserted unless the kernel buffer object pfns and user-space addresses align perfectly. There are various options here, but since buffer objects that reside in system pages typically start at huge page boundaries if they are backed by huge pages, we try to enforce buffer object starting pfns and user-space addresses to be huge page-size aligned if their size exceeds a huge page-size. If pud-size transhuge ("giant") pages are enabled by the arch, the same holds for those.Patch 6 implements a specialized
huge_faulthandler for vmwgfx. The vmwgfx driver may perform dirty-tracking and needs some special code to handle that correctly.Patch 7 implements a drm helper to align user-space addresses according to the above scheme, if possible.
Patch 8 implements a TTM range manager for vmwgfx that does the same for graphics IO memory. This may later be reused by other graphics drivers if necessary.
Patch 9 finally hooks up the helpers of patch 7 and 8 to the vmwgfx driver. A similar change is needed for graphics drivers that want a reasonable likelyhood of actually using huge page-table entries.
If a buffer object size is not huge-page or giant-page aligned, its size will NOT be inflated by this patchset. This means that the buffer object tail will use smaller size page-table entries and thus no memory overhead occurs. Drivers that want to pay the memory overhead price need to implement their own scheme to inflate buffer-object sizes.
PMD size huge page-table-entries have been tested with vmwgfx and found to work well both with system memory backed and IO memory backed buffer objects.
PUD size giant page-table-entries have seen limited (fault and COW) testing using a modified kernel (to support 1GB page allocations) and a fake vmwgfx TTM memory type. The vmwgfx driver does otherwise not support 1GB-size IO memory resources.
Comments and suggestions welcome.
ThomasChanges since RFC:
* Check for buffer objects present in contigous IO Memory (Christian König)
* Rebased on the vmwgfx emulated coherent memory functionality. That rebase adds patch 5.
Changes since v1:
* Make the new TTM range manager vmwgfx-specific. (Christian König)
* Minor fixes for configs that don't support or only partially support transhuge pages.
Changes since v2:
* Minor coding style and doc fixes in patch 5/9 (Christian König)
* Patch 5/9 doesn't touch mm. Remove from the patch title. Changes since v3:
* Added reviews and acks
* Implemented ugly but genericttm_pgprot_is_wrprotecting()instead of arch specific code.
Changes since v4:
* Added timings (Andrew Morton)
* Updated function documentation (Andrew Morton)
Changes since v6:
* Fix drm build error with !CONFIG_MMU[1]
The below test program generates the following gnu time output when run on a vmwgfx-enabled kernel without the patch series:4.78user 6.02system 0:10.91elapsed 99%CPU (0avgtext+0avgdata 1624maxresident)k 0inputs+0outputs (0major+640077minor)pagefaults 0swaps
and with the patch series:
1.71user 3.60system 0:05.40elapsed 98%CPU (0avgtext+0avgdata 1656maxresident)k 0inputs+0outputs (0major+20079minor)pagefaults 0swaps
A consistent number of reduced graphics page-faults can be seen with normal graphics applications, but due to the aggressive buffer object caching in vmwgfx user-space drivers the CPU time reduction is within the error marginal.
#include <
unistd.h>
#include <string.h>
#include <sys/mman.h>
#include <xf86drm.h>static void
checkerr(int ret, const char *name){ if (ret < 0) { perror(name); exit(-1); } }int
main(int agc, const char *argv[]){ struct drm_mode_create_dumb c_arg = {0}; struct drm_mode_map_dumb m_arg = {0}; struct drm_mode_destroy_dumb d_arg = {0}; int ret, i, fd; void *map; fd = open("/dev/dri/card0", O_RDWR); checkerr(fd, argv[0]); for (i = 0; i < 10000; ++i) { c_arg.bpp = 32; c_arg.width = 1024; c_arg.height = 1024; ret = drmIoctl(fd, DRM_IOCTL_MODE_CREATE_DUMB, &c_arg); checkerr(fd, argv[0]); m_arg.handle = c_arg.handle; ret = drmIoctl(fd, DRM_IOCTL_MODE_MAP_DUMB, &m_arg); checkerr(fd, argv[0]); map = mmap(NULL, c_arg.size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, m_arg.offset); checkerr(map == MAP_FAILED ? -1 : 0, argv[0]); (void) madvise((void *) map, c_arg.size, MADV_HUGEPAGE); memset(map, 0x67, c_arg.size); munmap(map, c_arg.size); d_arg.handle = c_arg.handle; ret = drmIoctl(fd, DRM_IOCTL_MODE_DESTROY_DUMB, &d_arg); checkerr(ret, argv[0]); } close(fd); }Cc Andrew Morton <[email protected]>Cc Michal Hocko <[email protected]>Cc "Matthew Wilcox (Oracle)" <[email protected]>Cc "Kirill A. Shutemov" <[email protected]>Cc Ralph Campbell <[email protected]>Cc "Jérôme Glisse" <[email protected]>Cc "Christian König" <[email protected]>Cc Dan Williams <[email protected]>
Quoted 4 lines
_______________________________________________
dri-devel mailing list
[email protected]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Cchristian.koenig%40amd.com%7Cbd52811a941244ba8b9908d7cfda99cb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637206410124474022&sdata=642fi4213qtdqtYCFfPNesOIDGmoYBuR4PeEzWMyfKE%3D&reserved=0
Hi, Christian,
I think this should be OK to merge now. Is it OK if I ask Dave to pull this separately?
Thanks,
Thomas
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel