From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
Matthew Auld <matthew.auld@intel.com>,
intel-gfx@lists.freedesktop.org
Cc: "Oak Zeng" <oak.zeng@intel.com>,
"Christian König" <christian.koenig@amd.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v9 2/8] drm/i915/ttm: add tt shmem backend
Date: Wed, 8 Dec 2021 09:39:44 +0100 [thread overview]
Message-ID: <508f76bc-4afc-4029-fc8a-eb8bb464a973@linux.intel.com> (raw)
In-Reply-To: <64b203a7-b09f-2982-ef3b-b33da7708d0f@linux.intel.com>
On 12/8/21 09:30, Tvrtko Ursulin wrote:
...
>>> Apart from the code organisation questions, on the practical level -
>>> do you need writeback from the TTM backend or while I am proposing
>>> to remove it from the "legacy" paths, I can propose removing it from
>>> the TTM flow as well?
>>
>> Yeah, if that is somehow busted then we should remove from TTM
>> backend also.
>
> Okay thanks, I wanted to check in case there was an extra need in TTM.
> I will float a patch soon hopefully but testing will be a problem
> since it seems very hard to repro at the moment.
Do we have some information about what's causing the deadlock or a
signature? I'm asking because if some sort of shrinker was added to TTM
itself, for the TTM page vectors, it would need to allocate shmem pages
at shrink time rather than to unpin them at shrink time as we do here.
And for that to have any chance of working sort of reliably, I think
writeback is needed.
But I agree for this implementation, the need for writeback isn't
different than for the non-TTM shmem objects
Thanks,
Thomas
>
> Regards,
>
> Tvrtko
next prev parent reply other threads:[~2021-12-08 8:39 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-18 9:10 [PATCH v9 1/8] drm/i915/gem: Break out some shmem backend utils Matthew Auld
2021-10-18 9:10 ` [PATCH v9 2/8] drm/i915/ttm: add tt shmem backend Matthew Auld
2021-12-07 13:10 ` [Intel-gfx] " Tvrtko Ursulin
2021-12-07 14:05 ` Matthew Auld
2021-12-08 8:30 ` Tvrtko Ursulin
2021-12-08 8:39 ` Thomas Hellström [this message]
2021-12-08 9:24 ` Tvrtko Ursulin
2021-12-08 9:32 ` Thomas Hellström
2021-10-18 9:10 ` [PATCH v9 3/8] drm/i915/gtt: drop unneeded make_unshrinkable Matthew Auld
2021-10-18 9:10 ` [PATCH v9 4/8] drm/i915: drop unneeded make_unshrinkable in free_object Matthew Auld
2021-10-18 9:10 ` [PATCH v9 5/8] drm/i915: add some kernel-doc for shrink_pin and friends Matthew Auld
2021-10-18 9:10 ` [PATCH v9 6/8] drm/i915/ttm: move shrinker management into adjust_lru Matthew Auld
2021-10-20 14:32 ` Thomas Hellström
2021-10-18 9:10 ` [PATCH v9 7/8] drm/i915/ttm: use cached system pages when evicting lmem Matthew Auld
2021-10-18 9:10 ` [PATCH v9 8/8] drm/i915/ttm: enable shmem tt backend Matthew Auld
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=508f76bc-4afc-4029-fc8a-eb8bb464a973@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=matthew.auld@intel.com \
--cc=oak.zeng@intel.com \
--cc=tvrtko.ursulin@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox