Re: recursive spinlocks. Shoot.

[Helge Hafting <helgehaf@aitel.hist.no>]

Nikita Danilov wrote:
> Consider two loops:
> 
> (1)
> 
> spin_lock(&lock);
> list_for_each_entry(item, ...) {
>   do something with item;
> }
> spin_unlock(&lock);
> 
> versus
> 
> (2)
> 
> list_for_each_entry(item, ...) {
>   spin_lock(&lock);
>   do something with item;
>   spin_unlock(&lock);
> }
> 
> and suppose they both are equally correct. Now, in (2) total amount of
> time &lock is held is smaller than in (1), but (2) will usually perform
> worse on SMP, because:
> 
> . spin_lock() is an optimization barrier
> 
> . taking even un-contended spin lock is an expensive operation, because
> of the cache coherency issues.


This is a tradeoff.  If the total running time is "short", use (1) for 
performance.
If the running time is "long" use (2) to avoid lock contention.

"long" time happens when the time wasted by other processors spinning
typically exceed the time wasted by repeated lock+unlock, or there
is excessive latency on some irq-blocking lock.

You can get the best of both worlds (low latency and few lock operations)
like this:

while(more work to do) {
   spin_lock(&lock);
   process one suitably sized batch of items
   spin_unlock(&lock);
}

This sort of thing certainly helped the VM system.

Helge Hafting