This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: Coldfire __lll_lock fails under heavy system stress
- From: Ed Slas <ed_slas at yahoo dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: "libc-ports at sourceware dot org" <libc-ports at sourceware dot org>
- Date: Thu, 1 Nov 2012 07:56:53 -0700 (PDT)
- Subject: Re: Coldfire __lll_lock fails under heavy system stress
- References: <1351715016.75654.YahooMailNeo@web161606.mail.bf1.yahoo.com> <Pine.LNX.4.64.1210312041440.31881@digraph.polyomino.org.uk>
- Reply-to: Ed Slas <ed_slas at yahoo dot com>
Joesph,?
Thanks for your time. I understand the kernel's atomic_cmpxchg_32() is most likely the issue, but note that most of the other platforms use a atomic lock in user space, then resort to the kernel to arbitrate contentions. The Coldfire port makes the?atomic_cmpxchg_32 kernel call first, when there is a user space atomic lock available (TAS instruction).
This said, I believe I have a 'better' way, i.e. follows the design of the other ports closer...and eliminates the dependency on the buggy atomic_cmpxchg_32.
Also note the coldfire TAS instruction was not added until the v4 version of this chip...so this is probably not a good fit for patching tip anyhow.?
Ed
----- Original Message -----
From: Joseph S. Myers <joseph@codesourcery.com>
To: Ed Slas <ed_slas@yahoo.com>
Cc: "libc-ports@sourceware.org" <libc-ports@sourceware.org>
Sent: Wednesday, October 31, 2012 3:43 PM
Subject: Re: Coldfire __lll_lock fails under heavy system stress
On Wed, 31 Oct 2012, Ed Slas wrote:
> I rarely delve this low into the code, so I cannot explain why this
> implementation fails, but it is very suspicious that the kernel (2.6.38)
> interrupt handler repositions the PC if it sees the PC at interrupt was
> in atomic_cmpxchg_32().
Given what you have described, there is no evidence for a bug in glibc
rather than the kernel (and so no evidence that the problem you see should
be fixed in glibc rather than the kernel).
--
Joseph S. Myers
joseph@codesourcery.com