Re: [Intel-gfx] Strange hugepages result?

From: Matthew Auld <matthew.william.auld@gmail.com>
To: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Matthew Auld <matthew.auld@intel.com>
Subject: Re: [Intel-gfx] Strange hugepages result?
Date: Thu, 10 Jun 2021 20:57:38 +0100	[thread overview]
Message-ID: <CAM0jSHMhXFKXzULOdVjQb_wM_oMqWTqvL1e-9jrhOTvPK37iyw@mail.gmail.com> (raw)
In-Reply-To: <c9ea7221-cc54-3394-f664-3f819ecc6d06@linux.intel.com>

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