lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 21 Dec 2012 22:58:48 -0500 From: Rik van Riel <riel@...hat.com> To: Steven Rostedt <rostedt@...dmis.org> CC: David Daney <ddaney.cavm@...il.com>, linux-kernel@...r.kernel.org, aquini@...hat.com, walken@...gle.com, lwoodman@...hat.com, jeremy@...p.org, Jan Beulich <JBeulich@...ell.com>, Thomas Gleixner <tglx@...utronix.de> Subject: Re: [RFC PATCH 3/3] x86,smp: auto tune spinlock backoff delay factor On 12/21/2012 10:49 PM, Steven Rostedt wrote: > On Fri, Dec 21, 2012 at 09:51:35PM -0500, Rik van Riel wrote: >> However, since spinlock contention should not be the >> usual state, and all a scalable lock does is make sure >> that N+1 CPUs does not perform worse than N CPUs, using >> scalable locks is a stop-gap measure. >> >> I believe a stop-gap measure should be kept as simple as >> we can. I am willing to consider moving to a per-lock >> delay factor if we can figure out an easy way to do it, >> but I would like to avoid too much extra complexity... > > Rik, > > I like your solution. It's rather simple and simple solutions tend to > end up being the closest to optimal. The more complex a solution gets, > the more it starts chasing fireflies. > Anyway, I'd like to see this code tested, and more benchmarks run > against it. Absolutely. I would love to see if this code actually causes regressions anywhere. It is simple enough that I suspect it will not, but there really is only one way to find out. The more people test this with different workloads on different SMP systems, the better. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists