locking: qspinlock
From: | Peter Zijlstra <peterz@infradead.org> | |
To: | Waiman Long <waiman.long@hp.com> | |
Subject: | [RFC][PATCH 0/7] locking: qspinlock | |
Date: | Mon, 10 Mar 2014 16:42:36 +0100 | |
Message-ID: | <20140310154236.038181843@infradead.org> | |
Cc: | arnd@arndb.de, linux-arch@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, rostedt@goodmis.org, akpm@linux-foundation.org, walken@google.com, andi@firstfloor.org, riel@redhat.com, paulmck@linux.vnet.ibm.com, torvalds@linux-foundation.org, oleg@redhat.com, Peter Zijlstra <peterz@infradead.org> | |
Archive‑link: | Article |
Hi Waiman, I promised you this series a number of days ago; sorry for the delay I've been somewhat unwell :/ That said, these few patches start with a (hopefully) simple and correct form of the queue spinlock, and then gradually build upon it, explaining each optimization as we go. Having these optimizations as separate patches helps twofold; firstly it makes one aware of which exact optimizations were done, and secondly it allows one to proove or disprove any one step; seeing how they should be mostly identity transforms. The resulting code is near to what you posted I think; however it has one atomic op less in the pending wait-acquire case for NR_CPUS != huge. It also doesn't do lock stealing; its still perfectly fair afaict. Have I missed any tricks from your code? The patches apply to tip/master + lkml.kernel.org/r/20140210195820.834693028@infradead.org I've yet to look at the paravirt stuff. -- 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/