Messages in this thread | | | Subject | Re: SMP syncronization on AMD processors (broken?) | From | Arjan van de Ven <> | Date | Thu, 06 Oct 2005 16:22:18 +0200 |
| |
On Thu, 2005-10-06 at 17:32 +0400, Andrey Savochkin wrote: > On Thu, Oct 06, 2005 at 03:19:07PM +0200, Arjan van de Ven wrote: > > On Thu, 2005-10-06 at 17:05 +0400, Kirill Korotaev wrote: > > > Hello Linus, Andrew and others, > > > > > > Please help with a not simple question about spin_lock/spin_unlock on > > > SMP archs. The question is whether concurrent spin_lock()'s should > > > acquire it in more or less "fair" fashinon or one of CPUs can starve any > > > arbitrary time while others do reacquire it in a loop. > > > > spinlocks are designed to not be fair. or rather are allowed to not be. > > If you want them to be fair on x86 you need at minimum to put a > > cpu_relax() in your busy loop... > > The question was raised exactly because cpu_relax() doesn't help on these AMD > CPUs. > > Some Pentiums do more than expected from them, and the programs works in a > very fair manner even without cpu_relax(), so the question boils down to > whether there are some new AMD rules how to write such loops, is it a defect > of the CPU, or if we are missing something else.
the rule basically is "don't write such a loop" though; this is only the beginning; because if you have two such things on separate cores of a dual core cpu you for sure starve anything outside of that core just the same. Eg it goes one level up as well.
There is no spin_lock_yield() currently and until there is this is just a code pattern you should avoid.
- 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/
| |