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
next prev parent 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.