>>> On Thu, Feb 21, 2008 at 4:42 PM, in message <20080221214219.GA27209@xxxxxxx>, Ingo Molnar <mingo@xxxxxxx> wrote: > * Bill Huey (hui) <bill.huey@xxxxxxxxx> wrote: > >> I came to the original conclusion that it wasn't originally worth it, >> but the dbench number published say otherwise. [...] > > dbench is a notoriously unreliable and meaningless workload. It's being > frowned upon by the VM and the IO folks. I agree...its a pretty weak benchmark. BUT, it does pound on dcache_lock and therefore was a good demonstration of the benefits of lower-contention overhead. Also note we also threw other tests in that PDF if you scroll to the subsequent pages. > If that's the only workload > where spin-mutexes help, and if it's only a 3% improvement [of which it > is unclear how much of that improvement was due to ticket spinlocks], > then adaptive mutexes are probably not worth it. Note that the "3%" figure being thrown around was from a single patch within the series. We are actually getting a net average gain of 443% in dbench. And note that the number goes *up* when you remove the ticketlocks. The ticketlocks are there to prevent latency spikes, not improve throughput. Also take a look at the hackbench numbers which are particularly promising. We get a net average gain of 493% faster for RT10 based hackbench runs. The kernel build was only a small gain, but it was all gain nonetheless. We see similar results for any other workloads we throw at this thing. I will gladly run any test requested to which I have the ability to run, and I would encourage third party results as well. > > I'd not exclude them fundamentally though, it's really the numbers that > matter. The code is certainly simple enough (albeit the .config and > sysctl controls are quite ugly and unacceptable - adaptive mutexes > should really be ... adaptive, with no magic constants in .configs or > else). We can clean this up, per your suggestions. > > But ... i'm somewhat sceptic, after having played with spin-a-bit > mutexes before. Its very subtle to get this concept to work. The first few weeks, we were getting 90% regressions ;) Then we had a breakthrough and started to get this thing humming along quite nicely. Regards, -Greg - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
