From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Matthew Auld <matthew.william.auld@gmail.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
Matthew Auld <matthew.auld@intel.com>
Subject: Re: [Intel-gfx] Strange hugepages result?
Date: Fri, 11 Jun 2021 07:44:41 +0200 [thread overview]
Message-ID: <f1e4bd6e-618d-12ce-a31c-65ef218acc87@linux.intel.com> (raw)
In-Reply-To: <CAM0jSHMhXFKXzULOdVjQb_wM_oMqWTqvL1e-9jrhOTvPK37iyw@mail.gmail.com>
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
prev parent reply other threads:[~2021-06-11 5:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
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 message]
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=f1e4bd6e-618d-12ce-a31c-65ef218acc87@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=matthew.auld@intel.com \
--cc=matthew.william.auld@gmail.com \
/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 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.