linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: "Thomas Hellström (VMware)" <thomas_os@shipmail.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org
Cc: pv-drivers@vmware.com, linux-graphics-maintainer@vmware.com,
	"Thomas Hellstrom" <thellstrom@vmware.com>,
	"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>
Subject: Re: [PATCH 7/8] drm/ttm: Introduce a huge page aligning TTM range manager.
Date: Wed, 4 Dec 2019 13:16:37 +0100	[thread overview]
Message-ID: <f87a03da-ea9d-fe2b-8069-8fe0bda57c12@amd.com> (raw)
In-Reply-To: <7223bee1-cb3f-3d88-a70b-f4e1a5088b76@shipmail.org>

Am 04.12.19 um 12:45 schrieb Thomas Hellström (VMware):
> On 12/4/19 12:13 PM, Christian König wrote:
>> Am 03.12.19 um 14:22 schrieb Thomas Hellström (VMware):
>>> From: Thomas Hellstrom <thellstrom@vmware.com>
>>>
>>> Using huge page-table entries require that the start of a buffer object
>>> is huge page size aligned. So introduce a ttm_bo_man_get_node_huge()
>>> function that attempts to accomplish this for allocations that are 
>>> larger
>>> than the huge page size, and provide a new range-manager instance that
>>> uses that function.
>>
>> I still don't think that this is a good idea.
>
> Again, can you elaborate with some specific concerns?

You seems to be seeing PUD as something optional.

>>
>> The driver/userspace should just use a proper alignment if it wants 
>> to use huge pages.
>
> There are drawbacks with this approach. The TTM alignment is a hard 
> constraint. Assume that you want to fit a 1GB buffer object into 
> limited VRAM space, and _if possible_ use PUD size huge pages. Let's 
> say there is 1GB available, but not 1GB aligned. The proper alignment 
> approach would fail and possibly start to evict stuff from VRAM just 
> to be able to accomodate the PUD alignment. That's bad. The approach I 
> suggest would instead fall back to PMD alignment and use 2MB page 
> table entries if possible, and as a last resort use 4K page table 
> entries.

And exactly that sounds like a bad idea to me.

Using 1GB alignment is indeed unrealistic in most cases, but for 2MB 
alignment we should really start to evict BOs.

Otherwise the address space can become fragmented and we won't be able 
de-fragment it in any way.

Additional to that 2MB pages is becoming mandatory for some hardware 
features. E.g. scanning out of system memory won't be possible with 4k 
pages in the future.

Regards,
Christian.

> Or do I misunderstand how you envision enforcing the alignment?
>
> Thanks,
>
> Thomas
>
>
>
>
>
>
>>
>> Regards,
>> Christian.
>>
>>>
>>> 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>
>>> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
>>> ---
>>>   drivers/gpu/drm/ttm/ttm_bo_manager.c | 92 
>>> ++++++++++++++++++++++++++++
>>>   include/drm/ttm/ttm_bo_driver.h      |  1 +
>>>   2 files changed, 93 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_manager.c 
>>> b/drivers/gpu/drm/ttm/ttm_bo_manager.c
>>> index 18d3debcc949..26aa1a2ae7f1 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_bo_manager.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_bo_manager.c
>>> @@ -89,6 +89,89 @@ static int ttm_bo_man_get_node(struct 
>>> ttm_mem_type_manager *man,
>>>       return 0;
>>>   }
>>>   +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>>> +static int ttm_bo_insert_aligned(struct drm_mm *mm, struct 
>>> drm_mm_node *node,
>>> +                 unsigned long align_pages,
>>> +                 const struct ttm_place *place,
>>> +                 struct ttm_mem_reg *mem,
>>> +                 unsigned long lpfn,
>>> +                 enum drm_mm_insert_mode mode)
>>> +{
>>> +    if (align_pages >= mem->page_alignment &&
>>> +        (!mem->page_alignment || align_pages % mem->page_alignment 
>>> == 0)) {
>>> +        return drm_mm_insert_node_in_range(mm, node,
>>> +                           mem->num_pages,
>>> +                           align_pages, 0,
>>> +                           place->fpfn, lpfn, mode);
>>> +    }
>>> +
>>> +    return -ENOSPC;
>>> +}
>>> +
>>> +static int ttm_bo_man_get_node_huge(struct ttm_mem_type_manager *man,
>>> +                    struct ttm_buffer_object *bo,
>>> +                    const struct ttm_place *place,
>>> +                    struct ttm_mem_reg *mem)
>>> +{
>>> +    struct ttm_range_manager *rman = (struct ttm_range_manager *) 
>>> man->priv;
>>> +    struct drm_mm *mm = &rman->mm;
>>> +    struct drm_mm_node *node;
>>> +    unsigned long align_pages;
>>> +    unsigned long lpfn;
>>> +    enum drm_mm_insert_mode mode = DRM_MM_INSERT_BEST;
>>> +    int ret;
>>> +
>>> +    node = kzalloc(sizeof(*node), GFP_KERNEL);
>>> +    if (!node)
>>> +        return -ENOMEM;
>>> +
>>> +    lpfn = place->lpfn;
>>> +    if (!lpfn)
>>> +        lpfn = man->size;
>>> +
>>> +    mode = DRM_MM_INSERT_BEST;
>>> +    if (place->flags & TTM_PL_FLAG_TOPDOWN)
>>> +        mode = DRM_MM_INSERT_HIGH;
>>> +
>>> +    spin_lock(&rman->lock);
>>> +    if (IS_ENABLED(CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD)) {
>>> +        align_pages = (HPAGE_PUD_SIZE >> PAGE_SHIFT);
>>> +        if (mem->num_pages >= align_pages) {
>>> +            ret = ttm_bo_insert_aligned(mm, node, align_pages,
>>> +                            place, mem, lpfn, mode);
>>> +            if (!ret)
>>> +                goto found_unlock;
>>> +        }
>>> +    }
>>> +
>>> +    align_pages = (HPAGE_PMD_SIZE >> PAGE_SHIFT);
>>> +    if (mem->num_pages >= align_pages) {
>>> +        ret = ttm_bo_insert_aligned(mm, node, align_pages, place, mem,
>>> +                        lpfn, mode);
>>> +        if (!ret)
>>> +            goto found_unlock;
>>> +    }
>>> +
>>> +    ret = drm_mm_insert_node_in_range(mm, node, mem->num_pages,
>>> +                      mem->page_alignment, 0,
>>> +                      place->fpfn, lpfn, mode);
>>> +found_unlock:
>>> +    spin_unlock(&rman->lock);
>>> +
>>> +    if (unlikely(ret)) {
>>> +        kfree(node);
>>> +    } else {
>>> +        mem->mm_node = node;
>>> +        mem->start = node->start;
>>> +    }
>>> +
>>> +    return 0;
>>> +}
>>> +#else
>>> +#define ttm_bo_man_get_node_huge ttm_bo_man_get_node
>>> +#endif
>>> +
>>> +
>>>   static void ttm_bo_man_put_node(struct ttm_mem_type_manager *man,
>>>                   struct ttm_mem_reg *mem)
>>>   {
>>> @@ -154,3 +237,12 @@ const struct ttm_mem_type_manager_func 
>>> ttm_bo_manager_func = {
>>>       .debug = ttm_bo_man_debug
>>>   };
>>>   EXPORT_SYMBOL(ttm_bo_manager_func);
>>> +
>>> +const struct ttm_mem_type_manager_func ttm_bo_manager_huge_func = {
>>> +    .init = ttm_bo_man_init,
>>> +    .takedown = ttm_bo_man_takedown,
>>> +    .get_node = ttm_bo_man_get_node_huge,
>>> +    .put_node = ttm_bo_man_put_node,
>>> +    .debug = ttm_bo_man_debug
>>> +};
>>> +EXPORT_SYMBOL(ttm_bo_manager_huge_func);
>>> diff --git a/include/drm/ttm/ttm_bo_driver.h 
>>> b/include/drm/ttm/ttm_bo_driver.h
>>> index cac7a8a0825a..868bd0d4be6a 100644
>>> --- a/include/drm/ttm/ttm_bo_driver.h
>>> +++ b/include/drm/ttm/ttm_bo_driver.h
>>> @@ -888,5 +888,6 @@ int ttm_bo_pipeline_gutting(struct 
>>> ttm_buffer_object *bo);
>>>   pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp);
>>>     extern const struct ttm_mem_type_manager_func ttm_bo_manager_func;
>>> +extern const struct ttm_mem_type_manager_func 
>>> ttm_bo_manager_huge_func;
>>>     #endif
>
>


  reply	other threads:[~2019-12-04 12:16 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-03 13:22 [PATCH 0/8] Huge page-table entries for TTM Thomas Hellström (VMware)
2019-12-03 13:22 ` [PATCH 1/8] mm: Introduce vma_is_special_huge Thomas Hellström (VMware)
2020-03-01  4:04   ` Andrew Morton
2019-12-03 13:22 ` [PATCH 2/8] mm: Split huge pages on write-notify or COW Thomas Hellström (VMware)
2020-03-01  4:04   ` Andrew Morton
2019-12-03 13:22 ` [PATCH 3/8] mm: Add vmf_insert_pfn_xxx_prot() for huge page-table entries Thomas Hellström (VMware)
2019-12-03 13:22 ` [PATCH 4/8] drm/ttm, drm/vmwgfx: Support huge TTM pagefaults Thomas Hellström (VMware)
2019-12-03 13:22 ` [PATCH 5/8] drm/vmwgfx: Support huge page faults Thomas Hellström (VMware)
2019-12-03 13:22 ` [PATCH 6/8] drm: Add a drm_get_unmapped_area() helper Thomas Hellström (VMware)
2019-12-04 11:11   ` Christian König
2019-12-04 11:36     ` Thomas Hellström (VMware)
2019-12-04 12:08       ` Christian König
2019-12-04 12:32         ` Thomas Hellström (VMware)
2019-12-04 14:40           ` Christian König
2019-12-04 15:36             ` Thomas Hellström (VMware)
2019-12-03 13:22 ` [PATCH 7/8] drm/ttm: Introduce a huge page aligning TTM range manager Thomas Hellström (VMware)
2019-12-04 11:13   ` Christian König
2019-12-04 11:45     ` Thomas Hellström (VMware)
2019-12-04 12:16       ` Christian König [this message]
2019-12-04 13:18         ` Thomas Hellström (VMware)
2019-12-04 14:02           ` Christian König
2019-12-03 13:22 ` [PATCH 8/8] drm/vmwgfx: Hook up the helpers to align buffer objects Thomas Hellström (VMware)
2020-03-01  4:04 ` [PATCH 0/8] Huge page-table entries for TTM Andrew Morton

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=f87a03da-ea9d-fe2b-8069-8fe0bda57c12@amd.com \
    --to=christian.koenig@amd.com \
    --cc=akpm@linux-foundation.org \
    --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=thellstrom@vmware.com \
    --cc=thomas_os@shipmail.org \
    --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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).