public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Hubertus Franke <frankeh@watson.ibm.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Futexes IV (Fast Lightweight Userspace Semaphores)
Date: Mon, 11 Mar 2002 09:14:17 -0500	[thread overview]
Message-ID: <20020311141315.D7BEE3FE06@smtp.linux.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0203081802540.5197-100000@penguin.transmeta.com>
In-Reply-To: <Pine.LNX.4.33.0203081802540.5197-100000@penguin.transmeta.com>

On Friday 08 March 2002 09:12 pm, Linus Torvalds wrote:
> On Fri, 8 Mar 2002, Hubertus Franke wrote:
> > > The point being that the difference between a "decl" and a "lock ; 
> > > decl" is about 1:12 or so in performance.
> >
> > I am no expert in architecture, but if its done through the cache
> > coherency mechanism, the overhead shouldn't be 12:1. You simply mark the
> > cache line as part of you instruction to avoid a cache line transfer. How
> > can that be 12 times slower.  .. Ready to be educated....
>
> A lock in a SMP system also needs to synchronize the instruction stream,
> and not let stores move "out" from the locked region.
>
> On a UP system, this all happens automatically (well, getting it to happen
> right is obviously one of the big issues in an out-of-order CPU core, but
> it's a very fundamental part of the core, so it's "free" in the sense that
> if it isn't done, the CPU simply doesn't work).
>
> On SMP, it's a memory barrier. This is why a "lock ; decl" is more
> expensive than a "decl" - it's the implied memory ordering constraints (on
> other architectures they are explicit). On an intel CPU, this basically
> means that the pipeline is drained, so a locked instruction takes roughly
> 12 cycles on a PPro core (AMD's K7 core seems to be rather more graceful
> about this one). I haven't timed a P4 lately, I think it's worse.
>
> Other architectures do the memory ordering explicitly, and some are
> better, some are worse. But it always costs you _something_.
>
> 		Linus


Sure, not contending that. Right now I think our focus should be to get the
right functionality out and address people's concerns.
Improvements, as you suggested, are orthogonal and can always be put
in later.

-- 
-- Hubertus Franke  (frankeh@watson.ibm.com)

  reply	other threads:[~2002-03-11 14:13 UTC|newest]

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-05  7:01 [PATCH] Futexes IV (Fast Lightweight Userspace Semaphores) Rusty Russell
2002-03-05 21:23 ` Futexes III : performance numbers Hubertus Franke
2002-03-06  2:08   ` Rusty Russell
2002-03-06 14:28     ` Hubertus Franke
2002-03-06 17:23       ` [Lse-tech] " george anzinger
2002-03-07  0:25     ` Hubertus Franke
2002-03-07  0:35     ` Hubertus Franke
2002-03-06  7:54   ` Rusty Russell
2002-03-06 14:46     ` Hubertus Franke
2002-03-06 16:13     ` Hubertus Franke
2002-03-06 20:36       ` Futexes V : Hubertus Franke
2002-03-07  4:21         ` Rusty Russell
2002-03-05 22:39 ` [PATCH] Futexes IV (Fast Lightweight Userspace Semaphores) Davide Libenzi
2002-03-05 23:16   ` Hubertus Franke
2002-03-05 23:26     ` Davide Libenzi
2002-03-05 23:37       ` Peter Svensson
2002-03-05 23:50         ` Davide Libenzi
2002-03-08  0:07       ` Richard Henderson
2002-03-06  1:46   ` Rusty Russell
2002-03-06  2:03     ` Davide Libenzi
2002-03-08 18:07 ` Linus Torvalds
2002-03-08 19:03   ` Hubertus Franke
2002-03-08 19:22     ` Linus Torvalds
2002-03-08 20:29       ` Hubertus Franke
2002-03-08 20:48         ` Matthew Kirkwood
2002-03-08 21:02         ` Linus Torvalds
2002-03-08 23:15           ` Hubertus Franke
2002-03-08 23:36             ` Alan Cox
2002-03-08 23:41             ` Linus Torvalds
2002-03-08 23:56               ` Hubertus Franke
2002-03-09  2:12                 ` Linus Torvalds
2002-03-11 14:14                   ` Hubertus Franke [this message]
2002-03-09  0:03               ` H. Peter Anvin
2002-03-09  1:15                 ` Alan Cox
2002-03-10 19:41                   ` Linus Torvalds
2002-03-11 20:49                     ` Pavel Machek
2002-03-13  7:40                     ` Rusty Russell
2002-03-13 16:37                       ` Alan Cox
2002-03-10 19:58                   ` Martin J. Bligh
2002-03-10 20:40                     ` Alan Cox
2002-03-10 20:28                       ` Martin J. Bligh
2002-03-10 21:05                         ` Alan Cox
2002-03-12  9:35                 ` Helge Hafting
2002-03-08 20:40       ` Alan Cox
2002-03-08 20:57         ` Linus Torvalds
2002-03-08 23:43           ` H. Peter Anvin
2002-03-08 22:55         ` Hubertus Franke
2002-03-08 23:38           ` Alan Cox
2002-03-08 23:44           ` H. Peter Anvin
2002-03-08 20:47       ` george anzinger
2002-03-08 23:02         ` Hubertus Franke
2002-03-08 23:47           ` george anzinger
2002-03-09  1:11             ` Alan Cox
2002-03-09  1:20             ` Linus Torvalds
2002-03-09  4:49       ` Rusty Russell
2002-03-11 22:45         ` Linus Torvalds
2002-03-11 23:12           ` Hubertus Franke
2002-03-12  7:20           ` Rusty Russell
2002-03-12 14:56             ` Hubertus Franke
2002-03-13  4:02               ` Rusty Russell
2002-03-12 17:17             ` Linus Torvalds
2002-03-13  2:57               ` Rusty Russell
2002-03-09  4:51   ` Rusty Russell
  -- strict thread matches above, loose matches on Subject: below --
2002-03-13  9:12 Martin Wirth
2002-03-13 19:41 ` Bill Davidsen
2002-03-13 19:52   ` Dave McCracken
2002-03-13 22:17     ` Bill Davidsen
2002-03-13 20:06   ` Alan Cox
2002-03-15  7:31 ` Rusty Russell
2002-03-15  8:41   ` Martin Wirth
2002-03-15 15:29     ` Hubertus Franke
2002-03-15 16:23     ` Peter Wächtler
2002-03-16  0:12       ` Rusty Russell
2002-03-16 11:23         ` Martin Wirth
2002-03-17  6:50           ` Rusty Russell
2002-03-18  0:52             ` Ulrich Drepper
2002-03-19  3:28               ` Rusty Russell
2002-03-19  4:05                 ` Ulrich Drepper
2002-03-20  6:20                   ` Rusty Russell
2002-03-20 10:42                     ` Peter Wächtler
2002-03-20 17:20                       ` Ulrich Drepper
2002-03-19  8:34                 ` Martin Wirth
2002-03-20  6:45                   ` Rusty Russell
2002-03-21  6:48                     ` Martin Wirth
2002-03-24 18:25                       ` Peter Wächtler
2002-03-25  2:28                         ` Rusty Russell
2002-03-25  4:46                           ` Rusty Russell
2002-03-25 11:56                             ` Peter Wächtler
2002-03-26  1:02                               ` Rusty Russell
2002-03-26  8:17                                 ` Martin Wirth
2002-03-26 23:10                                   ` Rusty Russell
2002-03-27 21:05                                     ` Hubertus Franke
2002-03-27 23:53                                       ` Rusty Russell
2002-03-25  9:47                           ` Peter Wächtler
2002-03-16 19:48         ` Peter Wächtler

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=20020311141315.D7BEE3FE06@smtp.linux.ibm.com \
    --to=frankeh@watson.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=torvalds@transmeta.com \
    /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