Messages in this thread | | | Subject | Re: [PATCH 6/8] drm: Add a drm_get_unmapped_area() helper | From | Thomas Hellström (VMware) <> | Date | Wed, 4 Dec 2019 16:36:35 +0100 |
| |
On 12/4/19 3:40 PM, Christian König wrote: > Am 04.12.19 um 13:32 schrieb Thomas Hellström (VMware): >> 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. > > I would opt for aligning the file offsets instead.
Yes but that adds additional complexity and considerations which made me think that lookup was the by far simplest choice:
- We need to modify the vma manager to care about alignments. - Fragmentation issues. Do we want to align > 1G BOs - For which drivers do we want to do this, how do we handle drivers that want to opt out in TTM mmap()? - Non TTM drivers. Could they still reuse the same get_unmapped_area.
> > Now that you explained it that the rest of the kernel enforces this > actually makes sense.
So is that an ack?
Thanks,
Thomas
> > Regards, > Christian. > >> >> Thanks, >> >> Thomas >> >>
| |