From: Benjamin LaHaise <bcrl@kvack.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Linus Torvalds <torvalds@osdl.org>, Andi Kleen <ak@suse.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>,
Arjan van de Ven <arjanv@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Christoph Hellwig <hch@infradead.org>,
David Howells <dhowells@redhat.com>,
Alexander Viro <viro@ftp.linux.org.uk>,
Oleg Nesterov <oleg@tv-sign.ru>
Subject: Re: [patch 00/15] Generic Mutex Subsystem
Date: Mon, 19 Dec 2005 15:19:44 -0500 [thread overview]
Message-ID: <20051219201944.GA17267@kvack.org> (raw)
In-Reply-To: <20051219201118.GA22198@elte.hu>
On Mon, Dec 19, 2005 at 09:11:18PM +0100, Ingo Molnar wrote:
> i think we also need to look at the larger picture. If this really is a
> bug that hid for years, it shows that the semaphore code is too complex
> to be properly reviewed and improved. Hence even assuming that the mutex
> code does not bring direct code advantages (which i'm disputing :-), the
> mutex code is far simpler and thus easier to improve. We humans have a
> given number of neurons, which form a hard limit :) In fact it's the
> mutex code that made it apparent that there's something wrong with
> semaphores.
True, but then the original semaphores weren't designed with fairness in
mind so much as being able to operate quickly. The commodity SMP hardware
that we have today has significantly different characteristics than the
first dual Pentium I used. I think there is significant room for improving
the implementation while still making it as tight and lean as possible. To
that end, adding state diagrams that make it easier to visualise what is
going on would be a big help. With that in place, it will be easier to
provide optimized fast paths with understandable logic.
> Just look at the semaphore implementations of various architectures,
> it's a quite colorful and inconsistent mix. Can you imagine adding
> deadlock debugging to each of them?
Agreed.
-ben
--
"You know, I've seen some crystals do some pretty trippy shit, man."
Don't Email: <dont@kvack.org>.
next prev parent reply other threads:[~2005-12-19 20:22 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-19 1:34 [patch 00/15] Generic Mutex Subsystem Ingo Molnar
2005-12-19 4:22 ` Andi Kleen
2005-12-19 4:28 ` Steven Rostedt
2005-12-19 4:31 ` Andi Kleen
2005-12-19 6:24 ` Linus Torvalds
2005-12-19 12:56 ` Steven Rostedt
2005-12-19 16:55 ` Ingo Molnar
2005-12-19 15:50 ` Ingo Molnar
2005-12-19 19:11 ` Linus Torvalds
2005-12-19 19:25 ` Benjamin LaHaise
2005-12-19 19:55 ` Linus Torvalds
2005-12-21 16:42 ` Oleg Nesterov
2006-01-10 10:28 ` Balbir Singh
2006-01-10 18:03 ` Oleg Nesterov
2006-01-11 6:33 ` Balbir Singh
2006-01-11 9:22 ` Oleg Nesterov
2005-12-19 20:11 ` Ingo Molnar
2005-12-19 20:19 ` Benjamin LaHaise [this message]
2005-12-19 20:32 ` Russell King
2005-12-19 20:57 ` Ingo Molnar
2005-12-19 19:55 ` Ingo Molnar
2005-12-19 20:12 ` Linus Torvalds
2005-12-19 23:37 ` Christoph Hellwig
2005-12-20 8:03 ` Nick Piggin
2005-12-20 8:06 ` Arjan van de Ven
2005-12-20 8:21 ` Nick Piggin
2005-12-20 8:36 ` Arjan van de Ven
2005-12-20 8:48 ` Nick Piggin
2005-12-19 16:22 ` 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=20051219201944.GA17267@kvack.org \
--to=bcrl@kvack.org \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjanv@infradead.org \
--cc=dhowells@redhat.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=oleg@tv-sign.ru \
--cc=rostedt@goodmis.org \
--cc=torvalds@osdl.org \
--cc=viro@ftp.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