mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jes Sorensen <jes@trained-monkey.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Linus Torvalds <torvalds@osdl.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>,
	Arjan van de Ven <arjanv@infradead.org>,
	Zwane Mwaikambo <zwane@arm.linux.org.uk>,
	Oleg Nesterov <oleg@tv-sign.ru>,
	David Howells <dhowells@redhat.com>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Benjamin LaHaise <bcrl@kvack.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Christoph Hellwig <hch@infradead.org>, Andi Kleen <ak@suse.de>,
	Russell King <rmk+lkml@arm.linux.org.uk>,
	Nicolas Pitre <nico@cam.org>
Subject: Re: [patch 0/8] mutex subsystem, ANNOUNCE
Date: 21 Dec 2005 13:07:48 -0500	[thread overview]
Message-ID: <yq0irtiuxvv.fsf@jaguar.mkp.net> (raw)
In-Reply-To: <20051221155411.GA7243@elte.hu>

>>>>> "Ingo" == Ingo Molnar <mingo@elte.hu> writes:

Ingo> this is the latest version of the mutex subsystem
Ingo> patch-queue. It consists of the following patches:

[snip]

Ingo> the patches are against Linus' latest tree, and were tested on
Ingo> i386, x86_64 and ia64. [the tests were also done in
Ingo> DEBUG_MUTEX_FULL mode, to make sure the code works
Ingo> fine. MUTEX_FULL support is not included in this patchqueue].

Hi,

I have been working with Ingo on porting this to ehe ia64 and run a
bunch of benchmarks using the DEBUG_MUTEX_FULL settings to see how it
behaves on various sized systems (8, 24 and 60 CPUs). In general I am
seeing speedups of roughly a factor 4 on XFS and 2.4 on TMPFS.

Below you will find the results. It's basically the same kernel
version with and without the mutex patch running in DEBUG_MUTEX_FULL
mode without debugging enabled. No other config options were changed.

I won't rule out any pilot errors, but at least it gives an idea about
the change in performance for a specific workload on different sized
boxes.

Cheers,
Jes


All tests on 2.6.15-rc6 with and without the mutex patch, using the
same test app used by Ingo. MUTEX refers to the mutex kernel and the
'no mutex' numbers are for the regular kernel.

I have run the tests on the following systems:

8-way system  (1.3GHz ia64)
24-way system (1.3GHz ia64)
60-way system (1.5GHz ia64)
===========================

Tests on XFS               MUTEX              NO MUTEX

8 CPUs, running 16 parallel test-tasks.
avg ops/sec:               173589             43136
average cost per op:       80.97 usecs        327.03 usecs
average cost per lock:     79.69 usecs        325.20 usecs
average cost per unlock:    1.28 usecs          1.83 usecs
average deviance per op:   65.75 usecs        191.65 usecs


24 CPUs, running 48 parallel test-tasks.
avg ops/sec:               156312             38976
average cost per op:       277.80 usecs       1087.65 usecs
average cost per lock:     276.06 usecs       1085.43 usecs
average cost per unlock:     1.74 usecs          2.22 usecs
average deviance per op:   229.80 usecs        613.78 usecs


60 CPUs, running 120 parallel test-tasks.
avg ops/sec:               188204             41794
average cost per op:       678.86 usecs	      2538.53 usecs
average cost per lock:     675.56 usecs	      2536.53 usecs
average cost per unlock:     3.29 usecs	         1.99 usecs
average deviance per op:   565.65 usecs	      1584.21 usecs

60 CPUs, running 540 parallel test-tasks.
avg ops/sec:               181230             44757
average cost per op:       3131.09 usecs      10711.06 usecs
average cost per lock:     3128.05 usecs      10709.21 usecs
average cost per unlock:      3.04 usecs          1.86 usecs
average deviance per op:   2525.36 usecs       6787.48 usecs


Tests on TMPFS             MUTEX              NO MUTEX
8 CPUs, running 16 parallel test-tasks.
avg ops/sec:               139621             57817
average cost per op:       100.70 usecs	      243.71 usecs
average cost per lock:      98.54 usecs	      242.28 usecs
average cost per unlock:     2.16 usecs	        1.43 usecs
average deviance per op:    76.03 usecs	      156.32 usecs

  parent reply	other threads:[~2005-12-21 18:07 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-21 15:54 Ingo Molnar
2005-12-21 16:04 ` Arjan van de Ven
2005-12-21 18:07 ` Jes Sorensen [this message]
2005-12-22  2:36   ` Nick Piggin
2005-12-22  2:57     ` Nick Piggin
2005-12-22  7:19     ` Ingo Molnar
2005-12-22  7:56       ` Nick Piggin
2005-12-22  8:00         ` Arjan van de Ven
2005-12-22  8:10           ` Nick Piggin
2005-12-22  8:21             ` Arjan van de Ven
2005-12-22  8:32               ` Nick Piggin
2005-12-22  8:24         ` Ingo Molnar
2005-12-22  8:37           ` Nick Piggin
2005-12-21 22:43 ` Nicolas Pitre
2005-12-21 22:43 ` [patch 1/3] mutex subsystem: fix additions to the ARM atomic.h Nicolas Pitre
2005-12-21 22:44 ` [patch 2/3] mutex subsystem: add new atomic primitives Nicolas Pitre
2005-12-21 22:44 ` [patch 3/3] mutex subsystem: move the core to the new atomic helpers Nicolas Pitre
2005-12-21 23:12   ` Ingo Molnar
2005-12-22  1:16     ` Matt Mackall
2005-12-22  6:50     ` Nicolas Pitre
2005-12-22  6:51     ` [patch 2/5] mutex subsystem: add architecture specific mutex primitives Nicolas Pitre
2005-12-22  7:44       ` Nick Piggin
2005-12-22  8:03         ` Nick Piggin
2005-12-22  6:52     ` [patch 1/5] mutex subsystem: fix asm-arm/atomic.h Nicolas Pitre
2005-12-22  6:53     ` [patch 3/5] mutex subsystem: move the core to the new atomic helpers Nicolas Pitre
2005-12-22  6:53     ` [patch 4/5] mutex subsystem: allow architecture defined fast path for mutex_lock_interruptible Nicolas Pitre
2005-12-22  6:53     ` [patch 5/5] mutex subsystem: allow for the fast path to be inlined Nicolas Pitre
2005-12-21 22:36 [patch 0/8] mutex subsystem, ANNOUNCE Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yq0irtiuxvv.fsf@jaguar.mkp.net \
    --to=jes@trained-monkey.org \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arjanv@infradead.org \
    --cc=bcrl@kvack.org \
    --cc=dhowells@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nico@cam.org \
    --cc=oleg@tv-sign.ru \
    --cc=rmk+lkml@arm.linux.org.uk \
    --cc=rostedt@goodmis.org \
    --cc=torvalds@osdl.org \
    --cc=zwane@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®