Linux-mm Archive on lore.kernel.org
 help / color / Atom feed
From: "Thomas Hellström (VMware)" <thomas_os@shipmail.org>
To: "Christian König" <christian.koenig@amd.com>,
	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 6/8] drm: Add a drm_get_unmapped_area() helper
Date: Wed, 4 Dec 2019 13:32:08 +0100
Message-ID: <90a8d09a-b3ab-cd00-0cfb-1a4c72e91836@shipmail.org> (raw)
In-Reply-To: <3cc5b796-20c6-9f4c-3f62-d844f34d81b7@amd.com>

On 12/4/19 1:08 PM, Christian König wrote:
> Am 04.12.19 um 12:36 schrieb Thomas Hellström (VMware):
>> On 12/4/19 12:11 PM, Christian König wrote:
>>> Am 03.12.19 um 14:22 schrieb Thomas Hellström (VMware):
>>>> From: Thomas Hellstrom <thellstrom@vmware.com>
>>>>
>>>> This helper is used to align user-space buffer object addresses to
>>>> huge page boundaries, minimizing the chance of alignment mismatch
>>>> between user-space addresses and physical addresses.
>>>
>>> Mhm, I'm wondering if that is really such a good idea.
>>
>> Could you elaborate? What drawbacks do you see?
>
> Main problem for me seems to be that I don't fully understand what the 
> get_unmapped_area callback is doing.

It makes sure that, if there is a chance that we could use huge 
page-table entries, virtual address huge page boundaries are perfectly 
aligned to physical address huge page boundaries, which is if not a CPU 
hardware requirement, at least a kernel requirement currently.


>
> For example why do we need to use drm_vma_offset_lookup_locked() to 
> adjust the pgoff?
>
> The mapped offset should be completely irrelevant for finding some 
> piece of userspace address space or am I totally off here?


Because the unmodified pgoff assumes that physical address boundaries 
are perfectly aligned with file offset boundaries, which is typical for 
all other subsystems.

That's not true for TTM, however, where a buffer object start physical 
address may be huge page aligned, but the file offset is always page 
aligned. We could of course change that to align also file offsets to 
huge page size boundaries, but with the above adjustment, that's not 
needed. I opted for the adjustment.

Thanks,

Thomas




  reply index

Thread overview: 20+ 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)
2019-12-03 13:22 ` [PATCH 2/8] mm: Split huge pages on write-notify or COW Thomas Hellström (VMware)
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) [this message]
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
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)

Reply instructions:

You may reply publically 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=90a8d09a-b3ab-cd00-0cfb-1a4c72e91836@shipmail.org \
    --to=thomas_os@shipmail.org \
    --cc=akpm@linux-foundation.org \
    --cc=christian.koenig@amd.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=thellstrom@vmware.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: link

Linux-mm Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-mm/0 linux-mm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-mm linux-mm/ https://lore.kernel.org/linux-mm \
		linux-mm@kvack.org
	public-inbox-index linux-mm

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kvack.linux-mm


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git