Messages in this thread |  | | | Date | Thu, 21 Feb 2008 14:56:28 -0700 | | From | "Gregory Haskins" <> | | Subject | Re: [PATCH [RT] 00/14] RFC - adaptive real-time locks | |
>>> On Thu, Feb 21, 2008 at 4:42 PM, in message <20080221214219.GA27209@elte.hu>,
Ingo Molnar <mingo@elte.hu> wrote:
> * Bill Huey (hui) <bill.huey@gmail.com> 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
|  |