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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri May 23 2003 - 22:00:54 EST