* [Intel-gfx] Strange hugepages result?
@ 2021-06-10 19:02 Thomas Hellström
2021-06-10 19:57 ` Matthew Auld
0 siblings, 1 reply; 3+ messages in thread
From: Thomas Hellström @ 2021-06-10 19:02 UTC (permalink / raw)
To: Matthew Auld, Intel Graphics Development
Hi, Matthew!
I got a funny result from the hugepages selftest when trying to break
out some functionality from shmem to make a ttm page pool for
cached-only TTM system bos.
It turns out that shmem computed the pagesizes using the underlying
pages rather than the dma segments, so when I changed that, hugepages
started failing.
https://patchwork.freedesktop.org/series/91227/
But when hacking the page-size computation to use the underlying pages,
it's fine again
https://patchwork.freedesktop.org/series/91336/
It seems like some assumption about huge dma segments is wrong, either
in our page-size calculation, in the selftest or in the actual huge page
setup. Could it be that huge sized segments are assumed to be properly
aligned?
/Thomas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Intel-gfx] Strange hugepages result?
2021-06-10 19:02 [Intel-gfx] Strange hugepages result? Thomas Hellström
@ 2021-06-10 19:57 ` Matthew Auld
2021-06-11 5:44 ` Thomas Hellström
0 siblings, 1 reply; 3+ messages in thread
From: Matthew Auld @ 2021-06-10 19:57 UTC (permalink / raw)
To: Thomas Hellström; +Cc: Intel Graphics Development, Matthew Auld
Hi,
On Thu, 10 Jun 2021 at 20:02, Thomas Hellström
<thomas.hellstrom@linux.intel.com> wrote:
>
> Hi, Matthew!
>
> I got a funny result from the hugepages selftest when trying to break
> out some functionality from shmem to make a ttm page pool for
> cached-only TTM system bos.
>
> It turns out that shmem computed the pagesizes using the underlying
> pages rather than the dma segments, so when I changed that, hugepages
> started failing.
>
> https://patchwork.freedesktop.org/series/91227/
>
> But when hacking the page-size computation to use the underlying pages,
> it's fine again
>
> https://patchwork.freedesktop.org/series/91336/
>
> It seems like some assumption about huge dma segments is wrong, either
> in our page-size calculation, in the selftest or in the actual huge page
> setup. Could it be that huge sized segments are assumed to be properly
> aligned?
We disabled THP for $reasons, so shrink_thp will pretty much always
skip I think, unless we happen to coalesce enough pages to make a 2M
page. I guess with your change that is somehow more likely now that we
use i915_sg_dma_sizes() and call it after we do the dma_map_sg. I
think the intel iommu driver also does coalescing or something. The
sg_page_sizes is mostly just a heuristic though.
The test failure looks like a bug in the test though, I think since
the object might still be active(gpu_write) we need to also force
SHRINK_ACTIVE, otherwise the shrinker will just ignore the object. The
test did work at some point but I guess has been modified/refactored a
few times.
We can either fix the test, or just delete it(igt_shrink_thp).
>
> /Thomas
>
>
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Intel-gfx] Strange hugepages result?
2021-06-10 19:57 ` Matthew Auld
@ 2021-06-11 5:44 ` Thomas Hellström
0 siblings, 0 replies; 3+ messages in thread
From: Thomas Hellström @ 2021-06-11 5:44 UTC (permalink / raw)
To: Matthew Auld; +Cc: Intel Graphics Development, Matthew Auld
On 6/10/21 9:57 PM, Matthew Auld wrote:
> Hi,
>
> On Thu, 10 Jun 2021 at 20:02, Thomas Hellström
> <thomas.hellstrom@linux.intel.com> wrote:
>> Hi, Matthew!
>>
>> I got a funny result from the hugepages selftest when trying to break
>> out some functionality from shmem to make a ttm page pool for
>> cached-only TTM system bos.
>>
>> It turns out that shmem computed the pagesizes using the underlying
>> pages rather than the dma segments, so when I changed that, hugepages
>> started failing.
>>
>> https://patchwork.freedesktop.org/series/91227/
>>
>> But when hacking the page-size computation to use the underlying pages,
>> it's fine again
>>
>> https://patchwork.freedesktop.org/series/91336/
>>
>> It seems like some assumption about huge dma segments is wrong, either
>> in our page-size calculation, in the selftest or in the actual huge page
>> setup. Could it be that huge sized segments are assumed to be properly
>> aligned?
> We disabled THP for $reasons, so shrink_thp will pretty much always
> skip I think, unless we happen to coalesce enough pages to make a 2M
> page. I guess with your change that is somehow more likely now that we
> use i915_sg_dma_sizes() and call it after we do the dma_map_sg. I
> think the intel iommu driver also does coalescing or something. The
> sg_page_sizes is mostly just a heuristic though.
>
> The test failure looks like a bug in the test though, I think since
> the object might still be active(gpu_write) we need to also force
> SHRINK_ACTIVE, otherwise the shrinker will just ignore the object. The
> test did work at some point but I guess has been modified/refactored a
> few times.
Ok makes sense. I'll see if I can fix the test then. And yes, the
difference in behavior is most likely due to the iommu driver coalescing
stuff.
/Thomas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-06-11 5:44 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-10 19:02 [Intel-gfx] Strange hugepages result? Thomas Hellström
2021-06-10 19:57 ` Matthew Auld
2021-06-11 5:44 ` Thomas Hellström
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.