linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Ingo Molnar <mingo@elte.hu>
Cc: Jes Sorensen <jes@trained-monkey.org>,
	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: Thu, 22 Dec 2005 18:56:05 +1100	[thread overview]
Message-ID: <43AA5C15.8060907@yahoo.com.au> (raw)
In-Reply-To: <20051222071940.GA16804@elte.hu>

Ingo Molnar wrote:
> * Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> 
> 
>>It would be nice to first do a run with a fair implementation of 
>>mutexes.
> 
> 
> which fairness implementation do you mean - the one where all tasks will 
> get the lock in fair FIFO order, and a 'lucky bastard' cannot steal the 
> lock from waiters and thus put them at an indefinite disadvantage?
> 

I guess so. I'm not so worried about the rare 'lucky bastard' ie. a
lock request coming in concurrently, but rather the naturally favoured
'this CPU' taking the lock again after waking up the head waiter but
before it gets a chance to run / transfer the cacheline.

At the very least, the head waiter should not put itself on the end of
the FIFO when it finds the lock contended and waits again.

But yes, also interesting would be performance of the _completely_ FIFO
implementation.

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 

  reply	other threads:[~2005-12-22  7:56 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-21 15:54 [patch 0/8] mutex subsystem, ANNOUNCE Ingo Molnar
2005-12-21 16:04 ` Arjan van de Ven
2005-12-21 18:07 ` Jes Sorensen
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 [this message]
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=43AA5C15.8060907@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --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=jes@trained-monkey.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;
as well as URLs for NNTP newsgroup(s).