From: "Thomas Hellström (VMware)" <thomas_os@shipmail.org> To: linux-mm@kvack.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Cc: pv-drivers@vmware.com, linux-graphics-maintainer@vmware.com, "Thomas Hellström" <thomas_os@shipmail.org>, "Andrew Morton" <akpm@linux-foundation.org>, "Michal Hocko" <mhocko@suse.com>, "Matthew Wilcox (Oracle)" <willy@infradead.org>, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, "Ralph Campbell" <rcampbell@nvidia.com>, "Jérôme Glisse" <jglisse@redhat.com>, "Christian König" <christian.koenig@amd.com>, "Dan Williams" <dan.j.williams@intel.com> Subject: [PATCH v2 0/9] Huge page-table entries for TTM Date: Fri, 24 Jan 2020 10:09:31 +0100 [thread overview] Message-ID: <20200124090940.26571-1-thomas_os@shipmail.org> (raw) In order to reduce TLB misses and CPU usage 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. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Michal Hocko <mhocko@suse.com> Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: "Jérôme Glisse" <jglisse@redhat.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Dan Williams <dan.j.williams@intel.com>
WARNING: multiple messages have this Message-ID (diff)
From: "Thomas Hellström (VMware)" <thomas_os@shipmail.org> To: linux-mm@kvack.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Cc: "Ralph Campbell" <rcampbell@nvidia.com>, "Michal Hocko" <mhocko@suse.com>, pv-drivers@vmware.com, "Thomas Hellström" <thomas_os@shipmail.org>, "Dan Williams" <dan.j.williams@intel.com>, "Matthew Wilcox (Oracle)" <willy@infradead.org>, "Jérôme Glisse" <jglisse@redhat.com>, linux-graphics-maintainer@vmware.com, "Andrew Morton" <akpm@linux-foundation.org>, "Christian König" <christian.koenig@amd.com>, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Subject: [PATCH v2 0/9] Huge page-table entries for TTM Date: Fri, 24 Jan 2020 10:09:31 +0100 [thread overview] Message-ID: <20200124090940.26571-1-thomas_os@shipmail.org> (raw) In order to reduce TLB misses and CPU usage 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. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Michal Hocko <mhocko@suse.com> Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: "Jérôme Glisse" <jglisse@redhat.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Dan Williams <dan.j.williams@intel.com> _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next reply other threads:[~2020-01-24 9:09 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-24 9:09 Thomas Hellström (VMware) [this message] 2020-01-24 9:09 ` [PATCH v2 0/9] Huge page-table entries for TTM Thomas Hellström (VMware) 2020-01-24 9:09 ` [PATCH 1/9] fs: Constify vma argument to vma_is_dax Thomas Hellström (VMware) 2020-01-24 9:09 ` Thomas Hellström (VMware) 2020-01-24 9:09 ` [PATCH 2/9] mm: Introduce vma_is_special_huge Thomas Hellström (VMware) 2020-01-24 9:09 ` Thomas Hellström (VMware) 2020-01-24 9:09 ` [PATCH 3/9] mm: Split huge pages on write-notify or COW Thomas Hellström (VMware) 2020-01-24 9:09 ` Thomas Hellström (VMware) 2020-01-24 9:09 ` [PATCH 4/9] mm: Add vmf_insert_pfn_xxx_prot() for huge page-table entries Thomas Hellström (VMware) 2020-01-24 9:09 ` Thomas Hellström (VMware) 2020-01-24 9:09 ` [PATCH 5/9] mm, drm/ttm, drm/vmwgfx: Support huge TTM pagefaults Thomas Hellström (VMware) 2020-01-24 9:09 ` Thomas Hellström (VMware) 2020-01-29 14:55 ` Christian König 2020-01-29 14:55 ` Christian König 2020-01-30 13:29 ` Thomas Hellström (VMware) 2020-01-30 13:29 ` Thomas Hellström (VMware) 2020-01-24 9:09 ` [PATCH 6/9] drm/vmwgfx: Support huge page faults Thomas Hellström (VMware) 2020-01-24 9:09 ` Thomas Hellström (VMware) 2020-01-24 9:09 ` [PATCH 7/9] drm: Add a drm_get_unmapped_area() helper Thomas Hellström (VMware) 2020-01-24 9:09 ` Thomas Hellström (VMware) 2020-01-24 9:09 ` [PATCH 8/9] drm/vmwgfx: Introduce a huge page aligning TTM range manager Thomas Hellström (VMware) 2020-01-24 9:09 ` Thomas Hellström (VMware) 2020-01-24 9:09 ` [PATCH 9/9] drm/vmwgfx: Hook up the helpers to align buffer objects Thomas Hellström (VMware) 2020-01-24 9:09 ` Thomas Hellström (VMware)
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200124090940.26571-1-thomas_os@shipmail.org \ --to=thomas_os@shipmail.org \ --cc=akpm@linux-foundation.org \ --cc=christian.koenig@amd.com \ --cc=dan.j.williams@intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=jglisse@redhat.com \ --cc=kirill.shutemov@linux.intel.com \ --cc=linux-graphics-maintainer@vmware.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@suse.com \ --cc=pv-drivers@vmware.com \ --cc=rcampbell@nvidia.com \ --cc=willy@infradead.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.