From: Joe Seigh <jseigh_02@xemaps.com>
To: linux-kernel@vger.kernel.org
Subject: Re: i386 spinlock fairness: bizarre test results
Date: Tue, 11 Oct 2005 08:31:33 -0400 [thread overview]
Message-ID: <digb50$4bd$1@sea.gmane.org> (raw)
In-Reply-To: <434B404F.9020508@shaw.ca>
Robert Hancock wrote:
> Chuck Ebbert wrote:
>
>> After seeing Kirill's message about spinlocks I decided to do my own
>> testing with the userspace program below; the results were very strange.
>>
>> When using the 'mov' instruction to do the unlock I was able to
>> reproduce
>> hogging of the spinlock by a single CPU even on Pentium II under some
>> conditions, while using 'xchg' always allowed the other CPU to get the
>> lock:
>
>
> This might not necessarily be a win in all situations. If two CPUs A and
> B are trying to get into a spinlock-protected critical section to do 5
> operations, it may well be more efficient for them to do AAAAABBBBB as
> opposed to ABABABABAB, as the second situation may result in cache lines
> bouncing between the two CPUs each time, etc.
>
> I don't know that making spinlocks "fairer" is really very worthwhile.
> If some spinlocks are so heavily contented that fairness becomes an
> issue, it would be better to find a way to reduce that contention.
>
You're right that it wouldn't be an issue on a system with relatively few
cpu's since that amount of contention would cripple the system. Though
with 100's of cpu's you could get contention hotspots with some spin locks
being concurrently accessed by some subset of the cpu's for periods of time.
The real issue is scalability or how gracefully does a system degrade
when it starts to hit its contention limits. It's not a good thing when
a system appears to run fine and then catastrophically hangs when it
bumps across its critical limit. It's better when a system exhibit's
some sort of linear degradation. The former exhibits bistable behavior
which requires a drastic, probably impossible, reduction in work load
to regain normal performance. Reboots are the normal course of correction.
The linearly degrading systems just require moderation of the workload
to move back into acceptable performance.
Anyway, if you want to build a scalable system, it makes sense to build it
out of scalable components. Right?
Joe Seigh
next prev parent reply other threads:[~2005-10-11 12:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[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 [this message]
2005-10-11 21:01 ` Bill Davidsen
2005-10-11 4:04 Chuck Ebbert
2005-10-11 9:42 ` Eric Dumazet
2005-10-11 13:00 ` Alan Cox
2005-10-11 14:44 ` Linus Torvalds
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='digb50$4bd$1@sea.gmane.org' \
--to=jseigh_02@xemaps.com \
--cc=linux-kernel@vger.kernel.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