All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Ingo Oeser <ioe-lkml@rameria.de>,
	linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
	Linus Torvalds <torvalds@osdl.org>,
	Jes Sorensen <jes@trained-monkey.org>, Greg KH <greg@kroah.com>
Subject: Re: [patch 00/62] sem2mutex: -V1
Date: Sat, 14 Jan 2006 14:38:40 +0100	[thread overview]
Message-ID: <20060114133840.GA4038@elte.hu> (raw)
In-Reply-To: <1137245466.3014.20.camel@laptopd505.fenrus.org>


* Arjan van de Ven <arjan@infradead.org> wrote:

> That case is the simple (and most common) case. Since it uses down() 
> only, it can't be irq context. (trylock could be a sign of irq context 
> use), and all up()'s are 1) not in irq context either because they're 
> in the same function as the down() which isn;t and 2) perfectly 
> matched to the down(), eg each down gets one up ---> perfect 
> semaphore.

one of the most frequent exceptions to the 'up in a separate function' 
rule are seqfile implementations, which all have start(), mid(), stop() 
methods, where start() does the down(), stop() does the up(). These can 
still be converted to mutexes (and i converted a couple of them), after 
manual review.

> The other case on the other side of the spectrum is a down in one 
> function and an up in an irq function. Which is a pretty good sign of 
> a completion.... (same is true for a specific scenario where kernel 
> thread creation is involved and the up() is done in the just created 
> thread).

another good sign of completion type of semaphores is the use of 
DECLARE_MUTEX_LOCKED(), init_MUTEX_LOCKED(), or sema_init(&sem, 0). In 
95% of these cases these signal semaphores used as completions. That is 
one reason why i did not add DEFINE_MUTEX_LOCKED(), nor 
mutex_init_locked() to the mutex APIs.

the 'struct work' conversion is rare, i've only seen it in XFS so far.

	Ingo

  reply	other threads:[~2006-01-14 13:38 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-13 12:44 [patch 00/62] sem2mutex: -V1 Ingo Molnar
2006-01-13 12:59 ` Duncan Sands
2006-01-13 13:06   ` Arjan van de Ven
2006-01-13 13:44   ` Ingo Molnar
2006-01-13 18:25     ` Ingo Oeser
2006-01-13 19:56       ` Ingo Molnar
2006-01-13 21:04         ` Matan Peled
2006-01-13 21:25           ` Arjan van de Ven
2006-01-13 22:09             ` Junio C Hamano
2006-01-13 22:13               ` Arjan van de Ven
2006-01-14 13:22           ` Ingo Oeser
2006-01-14 13:49             ` Thomas Gleixner
2006-01-14 13:16         ` Ingo Oeser
2006-01-14 13:31           ` Arjan van de Ven
2006-01-14 13:38             ` Ingo Molnar [this message]
2006-01-13 13:23 ` 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=20060114133840.GA4038@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@osdl.org \
    --cc=arjan@infradead.org \
    --cc=greg@kroah.com \
    --cc=ioe-lkml@rameria.de \
    --cc=jes@trained-monkey.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.