Re: [PATCH 10/28] drm/sched: Add fair scheduling policy

["Danilo Krummrich" <dakr@kernel.org>]

On Thu Oct 16, 2025 at 10:42 AM CEST, Tvrtko Ursulin wrote:
> Yes, I even said two replies ago I will add the lock. In fact, it is 
> write tearing which would be a problem on 32-bit architectures, not just 
> read tearing.
>
> But again, it is not a lockless algorithm and nowhere I am implementing 
> a new locking primitive. So as much as my attempt to keep it light 
> hearted with the warm and fuzzy feeling comment was a miss, I also think 
> the whole long writeups afterwards about dangers of implementing own 
> lockelss algorithms and performance were the same.

I think what's confusing people is the following:

	entity->stats->vruntime; /* Unlocked read */

You indicate with your comment that you are accessing something the is protected
by a lock intentionally without the lock being held.

I think there's not much room for people to interpret this as something else
than a lockless algorithm approach.

> So lets move on, there is no argument here.

Indeed, there is no argument. But, if you say something like:

"I can add the _existing_ entity->stats lock around it just as well for those
warm and fuzzy feelings."

it may be read by people as if you don't agree that for correctness either a
lock or an atomic is required. So, people might keep arguing regardless. :)