Re: [PATCH 1/3] drm/xe: Introduce a simple busted state

["Dixit, Ashutosh" <ashutosh.dixit@intel.com>]

On Fri, 15 Mar 2024 07:14:34 -0700, Tvrtko Ursulin wrote:
>
> On 15/03/2024 03:09, Rodrigo Vivi wrote:
> > On Thu, Mar 14, 2024 at 06:23:04PM -0700, Dixit, Ashutosh wrote:
> >> On Thu, 14 Mar 2024 18:03:15 -0700, Rodrigo Vivi wrote:
> >>>
> >>> Introduce a very simple 'busted' state where any attempt
> >>> to access the GPU is entirely blocked.
> >>
> >> Busted?
> >>
> >> busted. / (ˈbʌstəd) / adjective. informal caught out doing something wrong
> >> and therefore in trouble: you are so busted.
> >
> > that's why ;)
> >
> > also:
> > https://www.dictionary.com/browse/busted
> > "broken, fractured, or seriously damaged"
> >
> >>
> >> Why not wedged
> >
> > https://www.merriam-webster.com/dictionary/wedged : "shaped like a wedge" ? :)
> >
> > or perhaps this: https://dictionary.cambridge.org/us/dictionary/english/wedged
> >
> > "to make something stay in a particular position by using a wedge"
> >
> > "to put something into a very small or narrow space, so that it cannot move easily"
> >
> > that's the i915 terminology and meaning that I'm trying to avoid here...
> >
> > i.e. wedged can be a temporary state like in i915 where we 'wedge' and 'unwedge'
> > the gpu in so many cases. That flow doesn't fit well with xe scheduler and it is
> > a complication that is not desired.
> >
> > So I want a stronger word that makes it really clear that something went wrong
> > and won't easily transition back.
> >
> >>   or lost
> >
> > but not that strong...
> >
> > it is not entirely lost... we can still open the client, otherwise we would lose
> > display and also get the guc logs.
> >
> > If we really want to go lost and avoid the client connection then we could
> > simply deregister the drm card device for instance...
> >
> >> or down
> >
> > looks like 'off' without power...
> >
> >> or dead?
> >
> > too strong... like lost.
>
> Busted feels maybe not fully professional in the logs?

That was my concern too. However, looks like there is precedence for
"busted" in the kernel, e.g.

kernel/locking/locktorture.c:   .name = "lock_busted"
kernel/locking/locktorture.c:   &lock_busted_ops,
kernel/rcu/rcutorture.c: * The names includes "busted", and they really means it!

And 'git grep busted' yields other hits too.

> So if wedged really cannot be re-used for reduced congitive load

I don't really follow why wedged cannot be reused.

"
wedged

(computing, slang) Stuck; incapable of proceeding without help, though not
having crashed.  The server seems to be wedged: it's not even responding to
pings.
"

Are we thinking of introducing a wedged state in addition to a busted
state? We could have the wedged name but different behavior in Xe as
compared to i915. And seems in Xe un-wedge means devices unbind and
rebind. So using 'wedged' would result in comparison with i915 and
confusion and that's why we don't want to use it?

Anyway, maybe we can just get used to 'busted' too since there is
precedence for it.

Thanks.
--
Ashutosh




> then Merriam Webster lists 'jammed' as a synonym which has a pretty neat
> definitions.
>
> a
> : to become blocked, wedged, or stuck fast
> The line jammed and the boat hung useless.
>
> b
> : to become unworkable when a movable part becomes blocked or stuck
> the gun jammed
>
> Or 'off-lined' and maybe truly unregister the client as you say
> above. There is some benefit to avoiding funny words in kernel logs I
> think.
>
> Regards,
>
> Tvrtko
>
> >
> >>
> >> :-)
> >>
> >> Ashutosh