All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Michael Cheng <michael.cheng@intel.com>,
	intel-gfx@lists.freedesktop.org
Cc: wayne.boyer@intel.com, daniel.vetter@ffwll.ch,
	casey.g.bowman@intel.com, lucas.demarchi@intel.com,
	dri-devel@lists.freedesktop.org, chris@chris-wilson.co.uk,
	Matthew Auld <matthew.auld@intel.com>
Subject: Re: [PATCH 0/4] Drop wbinvd_on_all_cpus usage
Date: Mon, 21 Mar 2022 12:03:56 +0100	[thread overview]
Message-ID: <5db61477-6064-ada0-82a7-c1dc659dacad@linux.intel.com> (raw)
In-Reply-To: <4c86ae70-6f97-7a7c-1fd4-5e73ca29d0ba@linux.intel.com>

Hi, Tvrtko.

On 3/21/22 11:27, Tvrtko Ursulin wrote:
>
> On 19/03/2022 19:42, Michael Cheng wrote:
>> To align with the discussion in [1][2], this patch series drops all 
>> usage of
>> wbvind_on_all_cpus within i915 by either replacing the call with certain
>> drm clflush helpers, or reverting to a previous logic.
>
> AFAIU, complaint from [1] was that it is wrong to provide non x86 
> implementations under the wbinvd_on_all_cpus name. Instead an arch 
> agnostic helper which achieves the same effect could be created. Does 
> Arm have such concept?

I also understand Linus' email like we shouldn't leak incoherent IO to 
other architectures, meaning any remaining wbinvd()s should be X86 only.

Also, wbinvd_on_all_cpus() can become very costly, hence prefer the 
range apis when possible if they can be verified not to degrade performance.


>
> Given that the series seems to be taking a different route, avoiding 
> the need to call wbinvd_on_all_cpus rather than what [1] suggests 
> (note drm_clflush_sg can still call it!?), concern is that the series 
> has a bunch of reverts and each one needs to be analyzed.


Agreed.

/Thomas



>
> For instance looking at just the last one, 64b95df91f44, who has 
> looked at the locking consequences that commit describes:
>
> """
>     Inside gtt_restore_mappings() we currently take the 
> obj->resv->lock, but
>     in the future we need to avoid taking this fs-reclaim tainted lock 
> as we
>     need to extend the coverage of the vm->mutex. Take advantage of the
>     single-threaded nature of the early resume phase, and do a single
>     wbinvd() to flush all the GTT objects en masse.
>
> """
>
> ?
>
> Then there are suspend and freeze reverts which presumably can regress 
> the suspend times. Any data on those?
>
> Adding Matt since he was the reviewer for that work so might remember 
> something.
>
> Regards,
>
> Tvrtko
>
>
>> [1]. 
>> https://lists.freedesktop.org/archives/dri-devel/2021-November/330928.html
>> [2]. https://patchwork.freedesktop.org/patch/475752/?series=99991&rev=5
>>
>> Michael Cheng (4):
>>    i915/gem: drop wbinvd_on_all_cpus usage
>>    Revert "drm/i915/gem: Almagamate clflushes on suspend"
>>    i915/gem: Revert i915_gem_freeze to previous logic
>>    drm/i915/gt: Revert ggtt_resume to previous logic
>>
>>   drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c |  9 +---
>>   drivers/gpu/drm/i915/gem/i915_gem_pm.c     | 56 ++++++++++++++--------
>>   drivers/gpu/drm/i915/gt/intel_ggtt.c       | 17 +++----
>>   drivers/gpu/drm/i915/gt/intel_gtt.h        |  2 +-
>>   4 files changed, 46 insertions(+), 38 deletions(-)
>>

WARNING: multiple messages have this Message-ID (diff)
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Michael Cheng <michael.cheng@intel.com>,
	intel-gfx@lists.freedesktop.org
Cc: daniel.vetter@ffwll.ch, lucas.demarchi@intel.com,
	dri-devel@lists.freedesktop.org, chris@chris-wilson.co.uk,
	Matthew Auld <matthew.auld@intel.com>
Subject: Re: [Intel-gfx] [PATCH 0/4] Drop wbinvd_on_all_cpus usage
Date: Mon, 21 Mar 2022 12:03:56 +0100	[thread overview]
Message-ID: <5db61477-6064-ada0-82a7-c1dc659dacad@linux.intel.com> (raw)
In-Reply-To: <4c86ae70-6f97-7a7c-1fd4-5e73ca29d0ba@linux.intel.com>

Hi, Tvrtko.

On 3/21/22 11:27, Tvrtko Ursulin wrote:
>
> On 19/03/2022 19:42, Michael Cheng wrote:
>> To align with the discussion in [1][2], this patch series drops all 
>> usage of
>> wbvind_on_all_cpus within i915 by either replacing the call with certain
>> drm clflush helpers, or reverting to a previous logic.
>
> AFAIU, complaint from [1] was that it is wrong to provide non x86 
> implementations under the wbinvd_on_all_cpus name. Instead an arch 
> agnostic helper which achieves the same effect could be created. Does 
> Arm have such concept?

I also understand Linus' email like we shouldn't leak incoherent IO to 
other architectures, meaning any remaining wbinvd()s should be X86 only.

Also, wbinvd_on_all_cpus() can become very costly, hence prefer the 
range apis when possible if they can be verified not to degrade performance.


>
> Given that the series seems to be taking a different route, avoiding 
> the need to call wbinvd_on_all_cpus rather than what [1] suggests 
> (note drm_clflush_sg can still call it!?), concern is that the series 
> has a bunch of reverts and each one needs to be analyzed.


Agreed.

/Thomas



>
> For instance looking at just the last one, 64b95df91f44, who has 
> looked at the locking consequences that commit describes:
>
> """
>     Inside gtt_restore_mappings() we currently take the 
> obj->resv->lock, but
>     in the future we need to avoid taking this fs-reclaim tainted lock 
> as we
>     need to extend the coverage of the vm->mutex. Take advantage of the
>     single-threaded nature of the early resume phase, and do a single
>     wbinvd() to flush all the GTT objects en masse.
>
> """
>
> ?
>
> Then there are suspend and freeze reverts which presumably can regress 
> the suspend times. Any data on those?
>
> Adding Matt since he was the reviewer for that work so might remember 
> something.
>
> Regards,
>
> Tvrtko
>
>
>> [1]. 
>> https://lists.freedesktop.org/archives/dri-devel/2021-November/330928.html
>> [2]. https://patchwork.freedesktop.org/patch/475752/?series=99991&rev=5
>>
>> Michael Cheng (4):
>>    i915/gem: drop wbinvd_on_all_cpus usage
>>    Revert "drm/i915/gem: Almagamate clflushes on suspend"
>>    i915/gem: Revert i915_gem_freeze to previous logic
>>    drm/i915/gt: Revert ggtt_resume to previous logic
>>
>>   drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c |  9 +---
>>   drivers/gpu/drm/i915/gem/i915_gem_pm.c     | 56 ++++++++++++++--------
>>   drivers/gpu/drm/i915/gt/intel_ggtt.c       | 17 +++----
>>   drivers/gpu/drm/i915/gt/intel_gtt.h        |  2 +-
>>   4 files changed, 46 insertions(+), 38 deletions(-)
>>

  reply	other threads:[~2022-03-21 11:04 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-19 19:42 [PATCH 0/4] Drop wbinvd_on_all_cpus usage Michael Cheng
2022-03-19 19:42 ` [Intel-gfx] " Michael Cheng
2022-03-19 19:42 ` [PATCH 1/4] i915/gem: drop " Michael Cheng
2022-03-19 19:42   ` [Intel-gfx] " Michael Cheng
2022-03-21 10:30   ` Tvrtko Ursulin
2022-03-21 10:30     ` [Intel-gfx] " Tvrtko Ursulin
2022-03-21 11:07     ` Thomas Hellström
2022-03-21 11:07       ` [Intel-gfx] " Thomas Hellström
2022-03-21 18:51       ` Michael Cheng
2022-03-21 18:51         ` [Intel-gfx] " Michael Cheng
2022-03-21 16:31     ` Michael Cheng
2022-03-21 16:31       ` [Intel-gfx] " Michael Cheng
2022-03-21 17:28       ` Tvrtko Ursulin
2022-03-21 17:28         ` [Intel-gfx] " Tvrtko Ursulin
2022-03-21 17:42         ` Michael Cheng
2022-03-21 17:42           ` [Intel-gfx] " Michael Cheng
2022-03-22 14:35           ` Daniel Vetter
2022-03-22 14:35             ` Daniel Vetter
2022-03-21 17:51         ` Michael Cheng
2022-03-21 17:51           ` [Intel-gfx] " Michael Cheng
2022-03-19 19:42 ` [PATCH 2/4] Revert "drm/i915/gem: Almagamate clflushes on suspend" Michael Cheng
2022-03-19 19:42   ` [Intel-gfx] " Michael Cheng
2022-03-19 19:42 ` [PATCH 3/4] i915/gem: Revert i915_gem_freeze to previous logic Michael Cheng
2022-03-19 19:42   ` [Intel-gfx] " Michael Cheng
2022-03-19 19:42 ` [PATCH 4/4] drm/i915/gt: Revert ggtt_resume " Michael Cheng
2022-03-19 19:42   ` [Intel-gfx] " Michael Cheng
2022-03-19 20:15 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Drop wbinvd_on_all_cpus usage Patchwork
2022-03-19 20:16 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-03-19 20:45 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-03-19 22:04 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-03-21 10:27 ` [PATCH 0/4] " Tvrtko Ursulin
2022-03-21 10:27   ` [Intel-gfx] " Tvrtko Ursulin
2022-03-21 11:03   ` Thomas Hellström [this message]
2022-03-21 11:03     ` Thomas Hellström
2022-03-21 12:22     ` Tvrtko Ursulin
2022-03-21 12:22       ` [Intel-gfx] " Tvrtko Ursulin
2022-03-21 12:33       ` Thomas Hellström
2022-03-21 12:33         ` [Intel-gfx] " Thomas Hellström
2022-03-21 13:12         ` Tvrtko Ursulin
2022-03-21 13:12           ` [Intel-gfx] " Tvrtko Ursulin
2022-03-21 13:40           ` Thomas Hellström
2022-03-21 13:40             ` [Intel-gfx] " Thomas Hellström
2022-03-21 14:43             ` Tvrtko Ursulin
2022-03-21 14:43               ` [Intel-gfx] " Tvrtko Ursulin
2022-03-21 15:15               ` Thomas Hellström
2022-03-21 15:15                 ` [Intel-gfx] " Thomas Hellström
2022-03-22 10:13                 ` Tvrtko Ursulin
2022-03-22 10:13                   ` [Intel-gfx] " Tvrtko Ursulin
2022-03-22 10:26                   ` Thomas Hellström
2022-03-22 10:26                     ` [Intel-gfx] " Thomas Hellström
2022-03-22 10:41                     ` Thomas Hellström
2022-03-22 10:41                       ` [Intel-gfx] " Thomas Hellström
2022-03-22 11:20                     ` Tvrtko Ursulin
2022-03-22 11:20                       ` [Intel-gfx] " Tvrtko Ursulin
2022-03-22 11:37                       ` Thomas Hellström
2022-03-22 11:37                         ` [Intel-gfx] " Thomas Hellström
2022-03-22 12:53                         ` Tvrtko Ursulin
2022-03-22 12:53                           ` [Intel-gfx] " Tvrtko Ursulin
2022-03-22 15:07                           ` Thomas Hellström
2022-03-22 15:07                             ` [Intel-gfx] " Thomas Hellström

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=5db61477-6064-ada0-82a7-c1dc659dacad@linux.intel.com \
    --to=thomas.hellstrom@linux.intel.com \
    --cc=casey.g.bowman@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=matthew.auld@intel.com \
    --cc=michael.cheng@intel.com \
    --cc=tvrtko.ursulin@linux.intel.com \
    --cc=wayne.boyer@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 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.