On Thu, 21 Feb 2008 22:24:20 +0100 Ingo Molnar [EMAIL PROTECTED] wrote:
regarding the concept: adaptive mutexes have been talked about in the
past, but their advantage is not at all clear, that's why we havent done
them. It's definitely not an unambigiously win-win concept.
When ext3 was
The Real Time patches to the Linux kernel converts the architecture
specific SMP-synchronization primitives commonly referred to as
spinlocks to an RT mutex implementation that support a priority
inheritance protocol, and priority-ordered wait queues. The RT mutex
implementation allows tasks that
On Thu, Feb 21, 2008 at 10:26 AM, in message
[EMAIL PROTECTED], Gregory Haskins
[EMAIL PROTECTED] wrote:
We have put together some data from different types of benchmarks for
this patch series, which you can find here:
ftp://ftp.novell.com/dev/ghaskins/adaptive-locks.pdf
For convenience,
hm. Why is the ticket spinlock patch included in this patchset? It just
skews your performance results unnecessarily. Ticket spinlocks are
independent conceptually, they are already upstream in 2.6.25-rc2 and
-rt will have them automatically once we rebase to .25.
and if we take the ticket
It would also help to get the lockdep/lockstat output for those runs
so that more discussion can happen. That framework can be extended to
do all sorts of contention tracking and that is why I took implemented
it in the first place to track the viability of adaptive spins. My
initial results where
On Thu, Feb 21, 2008 at 4:24 PM, in message [EMAIL PROTECTED],
Ingo Molnar [EMAIL PROTECTED] wrote:
hm. Why is the ticket spinlock patch included in this patchset? It just
skews your performance results unnecessarily. Ticket spinlocks are
independent conceptually, they are already
On Thu, Feb 21, 2008 at 4:42 PM, in message [EMAIL PROTECTED],
Ingo Molnar [EMAIL PROTECTED] wrote:
* Bill Huey (hui) [EMAIL PROTECTED] wrote:
I came to the original conclusion that it wasn't originally worth it,
but the dbench number published say otherwise. [...]
dbench is a
On Thu, 2008-02-21 at 22:24 +0100, Ingo Molnar wrote:
hm. Why is the ticket spinlock patch included in this patchset? It just
skews your performance results unnecessarily. Ticket spinlocks are
independent conceptually, they are already upstream in 2.6.25-rc2 and
-rt will have them
On Thu, 2008-02-21 at 15:12 -0700, Peter W. Morreale wrote:
True, the ticket spinlock certainly adds to the throughput results we
have seen. However, the results without the ticket patch are still very
significant. (IIRC, 500-600MB/s instead of the ~730MB/s advertised) We
can easily re-gen
On Thu, Feb 21, 2008 at 1:42 PM, Ingo Molnar [EMAIL PROTECTED] wrote:
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
10 matches
Mail list logo
