mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Nicolas Pitre <nico@cam.org>
Cc: Ingo Molnar <mingo@elte.hu>,
	David Woodhouse <dwmw2@infradead.org>,
	Zwane Mwaikambo <zwane@arm.linux.org.uk>,
	lkml <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@osdl.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>, Andi Kleen <ak@suse.de>,
	David Howells <dhowells@redhat.com>,
	Alexander Viro <viro@parcelfarce.linux.theplanet.co.uk>,
	Oleg Nesterov <oleg@tv-sign.ru>, Paul Jackson <pj@sgi.com>
Subject: Re: [patch 04/15] Generic Mutex Subsystem, add-atomic-call-func-x86_64.patch
Date: Wed, 21 Dec 2005 02:05:56 +1100	[thread overview]
Message-ID: <43A81DD4.30906@yahoo.com.au> (raw)
In-Reply-To: <Pine.LNX.4.64.0512200927450.26663@localhost.localdomain>

Nicolas Pitre wrote:
> On Wed, 21 Dec 2005, Nick Piggin wrote:
> 
> 
>>Nicolas Pitre wrote:
>>
>>>On Tue, 20 Dec 2005, Nick Piggin wrote:
>>
>>>>Considering that on UP, the arm should not need to disable interrupts
>>>>for this function (or has someone refuted Linus?), how about:
>>>
>>>
>>>Kernel preemption.
>>>
>>
>>preempt_disable() ?
> 
> 
> Sure, and we're now more costly than the current implementation with irq 
> disabling.
> 

Why? It is just a plain increment of a location that will almost certainly
be in cache. I can't see how it would be more than half the cost of the
irq implementation (based on looking at your measurements). How do you
figure?

Also, preempt_disable is a very frequent operation on preempt kernels so
if you have CONFIG_PREEMPT then you don't care about preempt_disable in
down() (and if you do then you are calling down too often).

> If we go with simple mutexes that's because there is a gain, even a huge 
> one on ARM, especially for the fast uncontended case.  If you guys 
> insist on making things so generic and rigid then there is no gain 
> anymore worth the bother.
> 

I guess there is no bother for you, but maintaining code for 1 generic
platform versus two dozen architectures is a huge win for many.

-- 
SUSE Labs, Novell Inc.

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

  reply	other threads:[~2005-12-20 15:06 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-19  1:35 Ingo Molnar
2005-12-19 17:49 ` Zwane Mwaikambo
2005-12-19 20:58   ` David Woodhouse
2005-12-20  4:31     ` Ingo Molnar
2005-12-20  6:30       ` Nicolas Pitre
2005-12-20  8:12         ` Nick Piggin
2005-12-20 14:10           ` Nicolas Pitre
2005-12-20 14:12             ` Nick Piggin
2005-12-20 14:35               ` Nicolas Pitre
2005-12-20 15:05                 ` Nick Piggin [this message]
2005-12-20 16:35                   ` Nicolas Pitre
2005-12-20 19:20                     ` Russell King
2005-12-20 19:32                       ` Arjan van de Ven
2005-12-20 19:37                         ` Russell King
2005-12-20 19:59                         ` Nicolas Pitre
2005-12-20 19:43                       ` Steven Rostedt
2005-12-20 19:57                         ` Russell King
2005-12-20 20:35                         ` Horst von Brand
2005-12-20 19:55                       ` Nicolas Pitre
2005-12-20 18:27                 ` Linus Torvalds
2005-12-20 19:34                   ` Russell King
2005-12-20 20:10                     ` Linus Torvalds
2005-12-20 21:18                       ` Nicolas Pitre
2005-12-20 22:04                         ` Linus Torvalds
2005-12-20 22:19                           ` Steven Rostedt
2005-12-20 22:43                           ` Nicolas Pitre
2005-12-21  6:00                           ` Ingo Molnar
2005-12-21  2:12                         ` Nick Piggin
2005-12-20 19:49                   ` Nicolas Pitre
2005-12-20 18:25               ` Linus Torvalds
2005-12-21  6:20               ` Ingo Molnar
2005-12-21  4:16         ` Nicolas Pitre
2005-12-21  6:26           ` Ingo Molnar
2005-12-20  4:29   ` 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=43A81DD4.30906@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=dhowells@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nico@cam.org \
    --cc=oleg@tv-sign.ru \
    --cc=pj@sgi.com \
    --cc=rostedt@goodmis.org \
    --cc=torvalds@osdl.org \
    --cc=viro@parcelfarce.linux.theplanet.co.uk \
    --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®