On 11/30/2023 4:10 PM, Teres Alexis, Alan Previn wrote:
As far as i can tell, its only if we started resetting / wedging right after
this
queued worker got started.
alan: hope Daniele can proof read my tracing and confirm if got it right.
Yup, we don't flush the worker in reset prepare,
> As far as i can tell, its only if we started resetting / wedging right after
> this
> queued worker got started.
alan: hope Daniele can proof read my tracing and confirm if got it right.
On Thu, 2023-11-30 at 16:18 -0500, Vivi, Rodrigo wrote:
> On Wed, Nov 29, 2023 at 04:20:13PM -0800, Alan Previn wrote:
alan:snip
> > +
> > if (unlikely(disabled)) {
> > release_guc_id(guc, ce);
> > __guc_context_destroy(ce);
> > - return;
> > +
On Wed, Nov 29, 2023 at 04:20:13PM -0800, Alan Previn wrote:
> If we are at the end of suspend or very early in resume
> its possible an async fence signal (via rcu_call) is triggered
> to free_engines which could lead us to the execution of
> the context destruction worker (after a prior worker
If we are at the end of suspend or very early in resume
its possible an async fence signal (via rcu_call) is triggered
to free_engines which could lead us to the execution of
the context destruction worker (after a prior worker flush).
Thus, when suspending, insert rcu_barriers at the start
of
