public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Chuck Ebbert <76306.1226@compuserve.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	linux@horizon.com, Linus Torvalds <torvalds@osdl.org>,
	Kirill Korotaev <dev@sw.ru>
Subject: Re: i386 spinlock fairness: bizarre test results
Date: Tue, 11 Oct 2005 14:00:58 +0100	[thread overview]
Message-ID: <1129035658.23677.46.camel@localhost.localdomain> (raw)
In-Reply-To: <200510110007_MC3-1-AC4C-97EA@compuserve.com>

On Maw, 2005-10-11 at 00:04 -0400, Chuck Ebbert wrote:
>   That test machine was a dual 350MHz Pentium II Xeon; on a dual 333MHz Pentium II
> Overdrive (with very slow Socket 8 bus) I could not reproduce those results.
> However, on that machine the 'xchg' instruction made the test run almost 20%
> _faster_ than using 'mov'.
> 
>   So I think the i386 spinlock code should be changed to always use 'xchg' to do
> spin_unlock.


Using xchg on the spin unlock path is expensive. Really expensive on P4
compared to movb. It also doesn't guarantee anything either way around
especially as you go to four cores or change CPU (or in some cases quite
likely even chipset).

Spin lock paths should not be heavily contested. If they are then fix
the underlying problem with finer locking, or if you can't do that then
perhaps by serializing it with a queue.


  parent reply	other threads:[~2005-10-11 12:45 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-11  4:04 i386 spinlock fairness: bizarre test results Chuck Ebbert
2005-10-11  9:42 ` Eric Dumazet
2005-10-11 13:00 ` Alan Cox [this message]
2005-10-11 14:44   ` Linus Torvalds
2005-10-11 15:32     ` [PATCH] i386 spinlocks should use the full 32 bits, not only 8 bits Eric Dumazet
2005-10-11 16:03       ` Linus Torvalds
2005-10-11 16:36         ` Eric Dumazet
2005-10-11 16:54           ` Linus Torvalds
2005-10-11 16:55             ` Linus Torvalds
2005-10-17  7:03           ` Andrew Morton
2005-10-17  7:20             ` Arjan van de Ven
2005-10-20 21:50               ` Ingo Molnar
2005-10-20 21:57                 ` Linus Torvalds
2005-10-20 22:02                   ` Ingo Molnar
2005-10-20 22:15                     ` Linus Torvalds
2005-10-20 22:27                       ` Ingo Molnar
2005-10-20 22:44                         ` Andrew Morton
2005-10-20 22:53                           ` Ingo Molnar
2005-10-20 23:01                             ` Andrew Morton
2005-10-20 23:26                               ` Ingo Molnar
2005-10-27 16:54                                 ` Paul Jackson
2005-10-11 17:59         ` Andi Kleen
     [not found] <4WjCM-7Aq-7@gated-at.bofh.it>
2005-10-11  4:32 ` i386 spinlock fairness: bizarre test results Robert Hancock
2005-10-11 12:31   ` Joe Seigh
2005-10-11 21:01     ` Bill Davidsen

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=1129035658.23677.46.camel@localhost.localdomain \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=76306.1226@compuserve.com \
    --cc=dev@sw.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@horizon.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox