some doubt about spinlock vs mutex lock about uadk HOT 6 CLOSED

In a multi-threaded single ctx scenarios,other threads enter spinlock,will waste a lot cpu time to busy waiting util the one thread release it.

from uadk.

If we did not bind all thread to one cpu ,the performance gap between spinlock and mutex is very small.
So how should we handle this balance of cpu usage and performance?

from uadk.

In a multi-threaded single ctx scenarios,other threads enter spinlock,will waste a lot cpu time to busy waiting util the one thread release it.

It wasted some cpu time, but it gained the performance.

from uadk.

If we did not bind all thread to one cpu ,the performance gap between spinlock and mutex is very small.
So how should we handle this balance of cpu usage and performance?

Frankly speaking, it's very complex. We downplay the impact on locks. Because of lock, it causes context switch, cache trashing, and so on. All of them could impact the performance. For this case, I can't give a precise answer on which one is improved most since it's hard to measure.

From my view, reducing cpu usage could impact performance. Let's use an example to discuss. If driver/app is polling hardware, it costs a lot of CPU time and gains the performance. If interrupt is used, it saves CPU time and loses the performance.

Up to now, I received the command to tune performance. It means that people are not satisfied on the performance. As my understanding, it's always a trade-off on CPU usage and performance in system. Now it seems that tuning performance is in higher priority.

from uadk.

I have read some dpdk and roce code,they barely use spinlock. When they use it，it had to be used, because the io interface is called in interrupts.
But if we agreed performance have a higher priority than CPU consumption, we should not use mutex in this send and receive process, and I also saw a huge promote from your patch.
At least, we can run all thread on different ctx to reduce lock competition.

from uadk.

Close this issue based on the above discussion.

from uadk.