Messages in this thread | | | Date | Wed, 26 Dec 2012 22:07:50 -0800 | Subject | Re: [RFC PATCH 3/3 -v2] x86,smp: auto tune spinlock backoff delay factor | From | Michel Lespinasse <> |
| |
On Wed, Dec 26, 2012 at 11:51 AM, Rik van Riel <riel@redhat.com> wrote: > On 12/26/2012 02:10 PM, Eric Dumazet wrote: >> We might try to use a hash on lock address, and an array of 16 different >> delays so that different spinlocks have a chance of not sharing the same >> delay. >> >> With following patch, I get 982 Mbits/s with same bench, so an increase >> of 45 % instead of a 13 % regression.
Awesome :)
> I will probably keep it as a separate patch 4/4, with > your report and performance numbers in it, to preserve > the reason why we keep multiple hashed values, etc... > > There is enough stuff in this code that will be > indishinguishable from magic if we do not document it > properly...
If we go with per-spinlock tunings, I feel we'll most likely want to add an associative cache in order to avoid the 1/16 chance (~6%) of getting 595Mbit/s instead of 982Mbit/s when there is a hash collision.
I would still prefer if we could make up something that didn't require per-spinlock tunings, but it's not clear if that'll work. At least we now know of a simple enough workload to figure it out :)
-- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies.
| |