On 02/05/2019 04:07 PM, Alex Kogan wrote:

quoted

Doing time analysis on a randomized algorithm isn't my idea of fun.

quoted

It seems that even today, qspinlock does not support RT_PREEMPT, given
that it uses per-CPU queue nodes.

It does work with RT, commit:

 7aa54be29765 ("locking/qspinlock, x86: Provide liveness guarantee")

it a direct result of RT observing funnies with it. I've no idea why you
think it would not work.

Just trying to get to the bottom of it — as of today, qspinlock explicitly assumes
no preemption while waiting for the lock.

Here is what Waiman had to say about that in https://lwn.net/Articles/561775:

"The idea behind this spinlock implementation is the fact that spinlocks
are acquired with preemption disabled. In other words, the process
will not be migrated to another CPU while it is trying to get a
spinlock.”

This was back in 2013, but the code still uses per-CPU queue nodes,
and AFAICT, preemption will break things up.

So what you are saying is that RT would be fine assuming no preemption in
the spinlock as long as it provides FIFO? Or there is some future code patch 
that will take care of the “no preemption” assumption (but still assume FIFO)?

Thanks,
— Alex

Some of the critical sections protected by spinlocks may have execution
times that are much longer than desired. That is why they are converted
to rt-mutex in the RT kernel. There is another class of spinlocks called
raw spinlocks. They are the same as regular spinlocks in non RT-kernel,
but remain spinlocks with no preemption allowed in RT-kernel as sleeping
locks can't be used in atomic context. This is where the replacement of
the current qspinlock code by your NUMA-aware qspinlock may screw up the
timing guarantee that can be provided by the RT-kernel.

Cheers,
Longman


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel