All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Das, Nirmoy" <nirmoy.das@linux.intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Ville Syrjala <ville.syrjala@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Kick rcu harder to free objects
Date: Thu, 8 Sep 2022 21:22:49 +0200	[thread overview]
Message-ID: <8ebdf841-f118-d855-bf44-c189167cc05d@linux.intel.com> (raw)
In-Reply-To: <9ef06c2a-1ca6-7cf6-0f21-1722bdc4b4fb@linux.intel.com>


On 9/8/2022 4:55 PM, Tvrtko Ursulin wrote:
>
> On 08/09/2022 15:32, Das, Nirmoy wrote:
>> Hi Ville,
>>
>>
>> I fixed a similar issue in DII but I couldn't reproduce it in drm
>>
>> http://intel-gfx-pw.fi.intel.com/patch/228850/?series=15910&rev=2.
>>
>> I wonder if that fixes the problem you are facing then I can send 
>> that to drm.
>>
>> diff --git a/drivers/gpu/drm/i915/i915_gem.c 
>> b/drivers/gpu/drm/i915/i915_gem.c
>> index 7809be3a6840..5438e9277924 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.c
>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>> @@ -1213,7 +1213,7 @@  void i915_gem_init_early(struct 
>> drm_i915_private *dev_priv)
>>
>>   void i915_gem_cleanup_early(struct drm_i915_private *dev_priv)
>>   {
>> -    i915_gem_drain_freed_objects(dev_priv);
>> +    i915_gem_drain_workqueue(dev_priv);
>>       GEM_BUG_ON(!llist_empty(&dev_priv->mm.free_list));
>>       GEM_BUG_ON(atomic_read(&dev_priv->mm.free_count));
>>       drm_WARN_ON(&dev_priv->drm, dev_priv->mm.shrink_count);
>
> Yes why not, more black magic (count to three) but if it works... :) I 
> also spy the general area has been a bit neglected. Like:


Not sure what should be the correct solution here.  I wonder if we might 
have to change this because of

https://lwn.net/Articles/906975/ ?


>
> i915_gem_driver_remove:
> ...
>   i915_gem_drain_workqueue
>   i915_gem_drain_freed_objects
>
> While i915_gem_drain_workqueue:
> ...
>   i915_gem_drain_freed_objects
>
> So i915_gem_drain_freed_objects in i915_gem_driver_remove is redundant 
> already.
>
> Should i915_gem_drain_freed_objects be unexported and all callers made 
> just call i915_gem_drain_workqueue after your patch? Or if "drain free 
> objects" is considered more self descriptive it could be made as an 
> alias to i915_gem_drain_workqueue.


We are using i915_gem_drain_freed_objects() in many places and replacing 
that with i915_gem_drain_workqueue() might have performance implication.


Nirmoy


>
> Regards,
>
> Tvrtko
>
>>
>>
>> Regards,
>>
>> Nirmoy
>>
>> On 9/6/2022 7:46 PM, Ville Syrjala wrote:
>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>
>>> On gen3 the selftests are pretty much always tripping this:
>>> <4> [383.822424] pci 0000:00:02.0: 
>>> drm_WARN_ON(dev_priv->mm.shrink_count)
>>> <4> [383.822546] WARNING: CPU: 2 PID: 3560 at 
>>> drivers/gpu/drm/i915/i915_gem.c:1223 
>>> i915_gem_cleanup_early+0x96/0xb0 [i915]
>>>
>>> Looks to be due to the status page object lingering on the
>>> purge_list. Call synchronize_rcu() ahead of it to make more
>>> sure all objects have been freed.
>>>
>>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>> ---
>>>   drivers/gpu/drm/i915/i915_gem.c | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_gem.c 
>>> b/drivers/gpu/drm/i915/i915_gem.c
>>> index 0f49ec9d494a..5b61f7ad6473 100644
>>> --- a/drivers/gpu/drm/i915/i915_gem.c
>>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>>> @@ -1098,6 +1098,7 @@ void i915_gem_drain_freed_objects(struct 
>>> drm_i915_private *i915)
>>>           flush_delayed_work(&i915->bdev.wq);
>>>           rcu_barrier();
>>>       }
>>> +    synchronize_rcu();
>>>   }
>>>   /*

  reply	other threads:[~2022-09-08 19:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-06 17:46 [Intel-gfx] [PATCH] drm/i915: Kick rcu harder to free objects Ville Syrjala
2022-09-06 18:40 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2022-09-06 18:54 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-09-06 22:10 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-09-08 12:23 ` [Intel-gfx] [PATCH] " Tvrtko Ursulin
2022-09-08 13:30   ` Ville Syrjälä
2022-09-08 14:32 ` Das, Nirmoy
2022-09-08 14:55   ` Tvrtko Ursulin
2022-09-08 19:22     ` Das, Nirmoy [this message]
2022-09-08 15:11   ` Ville Syrjälä
2022-09-08 19:34     ` Das, Nirmoy
2022-09-09  7:29       ` Ville Syrjälä
2022-09-21  7:56         ` Ville Syrjälä
2022-09-22  8:39           ` Das, Nirmoy
2022-09-08 15:15 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Kick rcu harder to free objects (rev2) Patchwork

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=8ebdf841-f118-d855-bf44-c189167cc05d@linux.intel.com \
    --to=nirmoy.das@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=tvrtko.ursulin@linux.intel.com \
    --cc=ville.syrjala@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 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.