* [parisc-linux] User space locks -- what's wrong
@ 2006-06-04 23:55 John David Anglin
2006-06-05 14:40 ` Kyle McMartin
2006-06-07 1:30 ` Carlos O'Donell
0 siblings, 2 replies; 22+ messages in thread
From: John David Anglin @ 2006-06-04 23:55 UTC (permalink / raw)
To: parisc-linux
I'm about to throw the following change to the garbage heap since it
doesn't work as expected, particularly with SMP kernels.
The problem is I still see occasional libstdc++ and libjava testsuite
failures in pthread process intensive tests. In particular, I'm getting
timeouts on tests that didn't timeout before.
The enclosed change is based on ideas presented in the paper,
"Implementing Spinlocks on the Intel Itanium Architecture and PA-RISC".
The main issue that the change tries to address is that spinning
indefinitely in user space on a UP kernel just burns cycles. So, the
change is to spin awhile and then sleep. This seemed to work with
the test application in the paper, but in practice it seems to cause
more test failures that just spinning, particularly on SMP kernels.
I suspect that on SMP kernels we sometimes end up with all threads
sleeping.
I've tried various sleep routines including sched_yield, and other
optimizations, but they don't seem to make a difference. The trick
to dirty the cacheline presented in the paper didn't help performance
as measured by the Appendix F program. I also didn't see
and difference in performance using the ",co" completer. Possibly,
this is because I only tested on coherent PA 2.0 machines.
Thoughts?
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Index: libstdc++-v3/config/cpu/hppa/atomicity.h
===================================================================
--- libstdc++-v3/config/cpu/hppa/atomicity.h (revision 114341)
+++ libstdc++-v3/config/cpu/hppa/atomicity.h (working copy)
@@ -1,6 +1,6 @@
// Low-level functions for atomic operations: PA-RISC version -*- C++ -*-
-// Copyright (C) 2002, 2004, 2005 Free Software Foundation, Inc.
+// Copyright (C) 2002, 2004, 2005, 2006 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library. This library is free
// software; you can redistribute it and/or modify it under the
@@ -29,7 +29,21 @@
#include <bits/c++config.h>
#include <bits/atomicity.h>
+#include <sys/time.h>
+// Macro to execute the only PA_RISC atomic operation (load and clear word).
+// The operand A must point to the 16-byte aligned lock word. The result
+// is returned in V.
+#define PA_ASM_LOCK(a,v) \
+ __asm__ __volatile__ ("{ldcws|ldcw} 0(%1),%0" \
+ : "=r" (v) : "r" (a): "memory")
+
+// Macro to reset lock using an order PA 2.0 store. The operand A
+// must point to the lock word. The operand V must contain the value 1.
+#define PA_ASM_UNLOCK(a,v) \
+ __asm__ __volatile__ ("{stws|stw},ma %1,0(%0)" \
+ : : "r" (a), "r" (v) : "memory")
+
_GLIBCXX_BEGIN_NAMESPACE(__gnu_cxx)
template<int _Inst>
@@ -46,6 +60,32 @@
// linker, we explicitly instantiate the atomicity lock.
template volatile int _Atomicity_lock<0>::_S_atomicity_lock;
+ // Spin and sleep until we acquire the requested lock.
+ inline static void
+ __attribute__ ((__unused__))
+ _pa_getlock (volatile int *lptr)
+ {
+ int tmp;
+ unsigned int spins;
+ struct timeval sleeptime;
+
+ while (1)
+ {
+ // The number of spins should be one on a UP system.
+ for (spins = 100; spins; spins--)
+ {
+ PA_ASM_LOCK (lptr, tmp);
+ if (tmp != 0)
+ return;
+ }
+
+ // The sleep time choice isn't critical.
+ sleeptime.tv_sec = 0;
+ sleeptime.tv_usec = 5000;
+ select (0, 0, 0, 0, &sleeptime);
+ }
+ }
+
int
__attribute__ ((__unused__))
__exchange_and_add(volatile _Atomic_word* __mem, int __val)
@@ -54,21 +94,17 @@
int tmp;
volatile int& lock = _Atomicity_lock<0>::_S_atomicity_lock;
- __asm__ __volatile__ ("ldcw 0(%1),%0\n\t"
- "cmpib,<>,n 0,%0,.+20\n\t"
- "ldw 0(%1),%0\n\t"
- "cmpib,= 0,%0,.-4\n\t"
- "nop\n\t"
- "b,n .-20"
- : "=&r" (tmp)
- : "r" (&lock)
- : "memory");
-
+ PA_ASM_LOCK (&lock, tmp);
+ if (tmp == 0)
+ {
+ // Didn't get lock.
+ _pa_getlock (&lock);
+ }
+
result = *__mem;
*__mem = result + __val;
- /* Reset lock with PA 2.0 "ordered" store. */
- __asm__ __volatile__ ("stw,ma %1,0(%0)"
- : : "r" (&lock), "r" (tmp) : "memory");
+
+ PA_ASM_UNLOCK (&lock, tmp);
return result;
}
@@ -79,20 +115,17 @@
int tmp;
volatile int& lock = _Atomicity_lock<0>::_S_atomicity_lock;
- __asm__ __volatile__ ("ldcw 0(%1),%0\n\t"
- "cmpib,<>,n 0,%0,.+20\n\t"
- "ldw 0(%1),%0\n\t"
- "cmpib,= 0,%0,.-4\n\t"
- "nop\n\t"
- "b,n .-20"
- : "=&r" (tmp)
- : "r" (&lock)
- : "memory");
-
+ PA_ASM_LOCK (&lock, tmp);
+ if (tmp == 0)
+ {
+ // Didn't get lock.
+ _pa_getlock (&lock);
+ tmp = 1;
+ }
+
*__mem += __val;
- /* Reset lock with PA 2.0 "ordered" store. */
- __asm__ __volatile__ ("stw,ma %1,0(%0)"
- : : "r" (&lock), "r" (tmp) : "memory");
+
+ PA_ASM_UNLOCK (&lock, tmp);
}
_GLIBCXX_END_NAMESPACE
Index: libjava/sysdep/pa/locks.h
===================================================================
--- libjava/sysdep/pa/locks.h (revision 114341)
+++ libjava/sysdep/pa/locks.h (working copy)
@@ -1,6 +1,6 @@
// locks.h - Thread synchronization primitives. PA-RISC implementation.
-/* Copyright (C) 2002, 2005 Free Software Foundation
+/* Copyright (C) 2002, 2005, 2006 Free Software Foundation
This file is part of libgcj.
@@ -11,6 +11,8 @@
#ifndef __SYSDEP_LOCKS_H__
#define __SYSDEP_LOCKS_H__
+#include <sys/time.h>
+
// Integer type big enough for object address.
typedef size_t obj_addr_t;
@@ -28,6 +30,45 @@
// linker, we explicitly instantiate the atomicity lock.
template volatile int _pa_jv_cas_lock<0>::_S_pa_jv_cas_lock;
+// Macro to execute the only PA_RISC atomic operation (load and clear word).
+// The operand A must point to the 16-byte aligned lock word. The result
+// is returned in V.
+#define PA_ASM_LOCK(a,v) \
+ __asm__ __volatile__ ("{ldcws|ldcw} 0(%1),%0" \
+ : "=r" (v) : "r" (a): "memory")
+
+// Macro to reset lock using an order PA 2.0 store. The operand A
+// must point to the lock word. The operand V must contain the value 1.
+#define PA_ASM_UNLOCK(a,v) \
+ __asm__ __volatile__ ("{stws|stw},ma %1,0(%0)" \
+ : : "r" (a), "r" (v) : "memory")
+
+// Spin and sleep until we acquire the requested lock.
+inline static void
+__attribute__ ((__unused__))
+_pa_getlock (volatile int *lptr)
+{
+ int tmp;
+ unsigned int spins;
+ struct timeval sleeptime;
+
+ while (1)
+ {
+ // The number of spins should be one on a UP system.
+ for (spins = 100; spins; spins--)
+ {
+ PA_ASM_LOCK (lptr, tmp);
+ if (tmp != 0)
+ return;
+ }
+
+ // The sleep time choice isn't critical.
+ sleeptime.tv_sec = 0;
+ sleeptime.tv_usec = 5000;
+ select (0, 0, 0, 0, &sleeptime);
+ }
+}
+
// Atomically replace *addr by new_val if it was initially equal to old_val.
// Return true if the comparison is successful.
// Assumed to have acquire semantics, i.e. later memory operations
@@ -44,15 +85,13 @@
int tmp;
volatile int& lock = _pa_jv_cas_lock<0>::_S_pa_jv_cas_lock;
- __asm__ __volatile__ ("ldcw 0(%1),%0\n\t"
- "cmpib,<>,n 0,%0,.+20\n\t"
- "ldw 0(%1),%0\n\t"
- "cmpib,= 0,%0,.-4\n\t"
- "nop\n\t"
- "b,n .-20"
- : "=&r" (tmp)
- : "r" (&lock)
- : "memory");
+ PA_ASM_LOCK (&lock, tmp);
+ if (tmp == 0)
+ {
+ // Didn't get lock.
+ _pa_getlock (&lock);
+ tmp = 1;
+ }
if (*addr != old_val)
result = false;
@@ -62,10 +101,7 @@
result = true;
}
- /* Reset lock with PA 2.0 "ordered" store. */
- __asm__ __volatile__ ("stw,ma %1,0(%0)"
- : : "r" (&lock), "r" (tmp) : "memory");
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [parisc-linux] User space locks -- what's wrong
2006-06-04 23:55 [parisc-linux] User space locks -- what's wrong John David Anglin
@ 2006-06-05 14:40 ` Kyle McMartin
2006-06-05 16:49 ` John David Anglin
2006-06-07 1:30 ` Carlos O'Donell
1 sibling, 1 reply; 22+ messages in thread
From: Kyle McMartin @ 2006-06-05 14:40 UTC (permalink / raw)
To: John David Anglin; +Cc: parisc-linux
On Sun, Jun 04, 2006 at 07:55:58PM -0400, John David Anglin wrote:
> I'm about to throw the following change to the garbage heap since it
> doesn't work as expected, particularly with SMP kernels.
>
> The problem is I still see occasional libstdc++ and libjava testsuite
> failures in pthread process intensive tests. In particular, I'm getting
> timeouts on tests that didn't timeout before.
>
I don't suppose we could test this using locks based on Carlos'
light-weight-syscalls? This would have the added
> The enclosed change is based on ideas presented in the paper,
> "Implementing Spinlocks on the Intel Itanium Architecture and PA-RISC".
>
The changes look fine to me.
> The main issue that the change tries to address is that spinning
> indefinitely in user space on a UP kernel just burns cycles. So, the
> change is to spin awhile and then sleep. This seemed to work with
> the test application in the paper, but in practice it seems to cause
> more test failures that just spinning, particularly on SMP kernels.
> I suspect that on SMP kernels we sometimes end up with all threads
> sleeping.
>
That's absolutely bizarre. Can you include steps for us toolchain
newbies to reproduce this? I'd love to try and trace down why this is
occuring. It could be a problem indicative of something very funky
occuring in our kernel.
> I've tried various sleep routines including sched_yield, and other
> optimizations, but they don't seem to make a difference. The trick
> to dirty the cacheline presented in the paper didn't help performance
> as measured by the Appendix F program. I also didn't see
> and difference in performance using the ",co" completer. Possibly,
> this is because I only tested on coherent PA 2.0 machines.
>
I suspect a majority of this is because we aren't running
optimally as it is. I suspect if we were performing as well as HPUX
the minor details would make more of a difference.
Cheers,
Kyle
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [parisc-linux] User space locks -- what's wrong
2006-06-05 14:40 ` Kyle McMartin
@ 2006-06-05 16:49 ` John David Anglin
2006-06-05 17:40 ` James Bottomley
0 siblings, 1 reply; 22+ messages in thread
From: John David Anglin @ 2006-06-05 16:49 UTC (permalink / raw)
To: Kyle McMartin; +Cc: parisc-linux
> That's absolutely bizarre. Can you include steps for us toolchain
> newbies to reproduce this? I'd love to try and trace down why this is
> occuring. It could be a problem indicative of something very funky
> occuring in our kernel.
There definitely are some funky things going on in the kernel.
For example, if I try to build GCC with 'make -j 4 bootstrap' on
gsyprf11, about 50% of the time make dies because of a malloc data
corruption or a shell problem. However, I never see this with
just 'make bootstrap'.
It's crossed my mind that locking could break if there is a memory
aliasing issue,
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [parisc-linux] User space locks -- what's wrong
2006-06-05 16:49 ` John David Anglin
@ 2006-06-05 17:40 ` James Bottomley
0 siblings, 0 replies; 22+ messages in thread
From: James Bottomley @ 2006-06-05 17:40 UTC (permalink / raw)
To: John David Anglin; +Cc: Kyle McMartin, parisc-linux
On Mon, 2006-06-05 at 12:49 -0400, John David Anglin wrote:
> It's crossed my mind that locking could break if there is a memory
> aliasing issue,
This should never happen, since all our mmap areas are allocated on the
congruence boundary. DaveM recently pointed out that mremap can violate
the congruence rules on sparc. This could theoretically also happen on
pa, but only if you're enlarging below, which is an unusual case.
I did catch a few congruence errors when I redid the cache flushing via
tmpalias space, but it all looked to be due to kernel processes which
don't allocate correctly anyway ... and would never take user locks.
But I should probably get back and try to identify all the processes
with this problem.
James
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [parisc-linux] User space locks -- what's wrong
2006-06-04 23:55 [parisc-linux] User space locks -- what's wrong John David Anglin
2006-06-05 14:40 ` Kyle McMartin
@ 2006-06-07 1:30 ` Carlos O'Donell
2006-06-07 4:09 ` John David Anglin
2006-06-11 21:56 ` John David Anglin
1 sibling, 2 replies; 22+ messages in thread
From: Carlos O'Donell @ 2006-06-07 1:30 UTC (permalink / raw)
To: John David Anglin, parisc-linux
On 6/4/06, John David Anglin <dave@hiauly1.hia.nrc.ca> wrote:
> I'm about to throw the following change to the garbage heap since it
> doesn't work as expected, particularly with SMP kernels.
>
> The problem is I still see occasional libstdc++ and libjava testsuite
> failures in pthread process intensive tests. In particular, I'm getting
> timeouts on tests that didn't timeout before.
These could very well be related to our linuxthreads implementation?
It could be related to a problem with signals, which manifests as a
thread-manager issue, which under linuxthreads can break everything.
The thread-manager does all of it's work using a pipe and signals...
lots and lots of signals.
> The enclosed change is based on ideas presented in the paper,
> "Implementing Spinlocks on the Intel Itanium Architecture and PA-RISC".
>
> The main issue that the change tries to address is that spinning
> indefinitely in user space on a UP kernel just burns cycles. So, the
> change is to spin awhile and then sleep. This seemed to work with
> the test application in the paper, but in practice it seems to cause
> more test failures that just spinning, particularly on SMP kernels.
> I suspect that on SMP kernels we sometimes end up with all threads
> sleeping.
>
> I've tried various sleep routines including sched_yield, and other
> optimizations, but they don't seem to make a difference. The trick
> to dirty the cacheline presented in the paper didn't help performance
> as measured by the Appendix F program. I also didn't see
> and difference in performance using the ",co" completer. Possibly,
> this is because I only tested on coherent PA 2.0 machines.
>
> Thoughts?
You've implemented almost exactly what glibc does for pthreads.
However, glibc uses nanosleep without any adverse effects.
Have you tried other syscalls instead of select?
Cheers,
Carlos.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [parisc-linux] User space locks -- what's wrong
2006-06-07 1:30 ` Carlos O'Donell
@ 2006-06-07 4:09 ` John David Anglin
2006-06-07 12:25 ` Michael S. Zick
2006-06-11 21:56 ` John David Anglin
1 sibling, 1 reply; 22+ messages in thread
From: John David Anglin @ 2006-06-07 4:09 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: parisc-linux
> > Thoughts?
>
> You've implemented almost exactly what glibc does for pthreads.
> However, glibc uses nanosleep without any adverse effects.
> Have you tried other syscalls instead of select?
I've also tried nanosleep and sched_yield. I would say that
nanosleep and select have similar behavior under linux. I need
a little testing under hpux but I currently have the impression
that the patch with either nanosleep or select works under hpux.
I've had a coupled of failures that seemed to indicate a problem
with nanosleep, but I don't have hard data on this. Oh, I remember.
These were unkillable java tasks. strace indicated a nanosleep
call to the kernel that never returned. I couldn't find a signal
to get rid of the task. Haven't seen one of these for a few days.
Sometimes they are left over from the libjava testsuite run.
My initial testing with the program from the paper modified to
8 threads seemed to indicate somewhat poorer performance using
sched_yield (don't know why). I also found that pre-checks
of the lock using "ldw" or trying to create a dirty cache-line
prior to the ldcw didn't help overall performance. Using stby,e
to the high byte of the lock was definitely detrimental.
I think I can understand the later. I believe most PA 2.0 machines
are fully coherent (except V class and possibly superdome). Thus,
the ldcw instruction runs in cache on these machines and specifying
the ",co" completer doesn't matter. Also, stby,e is just an unnecessary
operation that occurs normally with ldcw if necessary. There might
be some effect on early PA 1.x machines which don't support executing
ldcw in cache.
There are some subtle cache issues in all this. I believe that
machines using the PA7200 through to the PA8700 only utilize an
L1 cache, but it has an assist buffer. It appears using the ",sl"
completer bypasses the L1 cache. Michael Zick thought using this
to reset the lock and in lock tests was a good idea, but think
it's better to use the L1. The effect of ",sl" on cacheline states
is rather poorly document. Michael has looked at some of HP's
patents and a bunch of other papers, but I'm not convinced. The
PDC_CACHE command may be able to change the coherency state and
write-back/write-through state of the data caches on some machines.
The cache design was changed on the PA8800 and PA8900. The L1
is now on-chip and there is a large L2. The cacheline length
also increased from 64 to 128 bytes. These changes could be
part of the reason linux still doesn't run on these machines.
Some of the papers talk about sharing and false sharing. These
can potentially cause failure of ldcw (race condition in bus logic?).
It is best is semaphores are cacheline aligned and don't share the line.
Currently, non of the locks used in arch/parisc are cacheline aligned.
Joel ran a test kernel with a patch to align statically allocated
locks. It might have run a bit longer than average but there was
still a softlockup after a few days. So, I don't think the lockup
is due to the spinlock design per say, although I could easily
be wrong. I think it's more likely to be something to do with
interrupt handling. This is suggested by the stack traces which
often seem to occur in the interrupt return path.
I've looked at the locking in hpux a bit. As far as I can tell,
the kernel never really spins. It has code to do pre-arbitration
and keeps track of tasks and priorities. When a lock is released,
the code calls into suwaiters to see if the lock should be handed
over to another task or released. When we just spin, we are relying
on the bus arbitration to select a winner. So, when we have a
highly contended lock, it might be possible for a cpu to get locked
out for sufficient time to cause a softlockup.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [parisc-linux] User space locks -- what's wrong
2006-06-07 4:09 ` John David Anglin
@ 2006-06-07 12:25 ` Michael S. Zick
2006-06-10 17:41 ` Michael S. Zick
0 siblings, 1 reply; 22+ messages in thread
From: Michael S. Zick @ 2006-06-07 12:25 UTC (permalink / raw)
To: parisc-linux
On Tue June 6 2006 23:09, John David Anglin wrote:
>
> There are some subtle cache issues in all this. I believe that
> machines using the PA7200 through to the PA8700 only utilize an
> L1 cache, but it has an assist buffer. It appears using the ",sl"
> completer bypasses the L1 cache. Michael Zick thought using this
> to reset the lock and in lock tests was a good idea, but think
> it's better to use the L1. The effect of ",sl" on cacheline states
> is rather poorly document. Michael has looked at some of HP's
> patents and a bunch of other papers, but I'm not convinced. The
> PDC_CACHE command may be able to change the coherency state and
> write-back/write-through state of the data caches on some machines.
>
I suspect that the problem is more subtle than our testing.
My mind is still spinning on how to write a good test.
Working only with public documents leaves more than one gray area.
> The cache design was changed on the PA8800 and PA8900. The L1
> is now on-chip and there is a large L2. The cacheline length
> also increased from 64 to 128 bytes. These changes could be
> part of the reason linux still doesn't run on these machines.
>
There are two other possibilities with the dual-core processors;
1) The on-chip caches are _publicly_ documented to not do cache-line
passing internally. Cache-lines are still passed over the external
buss. This may be a gray area in the public documents.
2) The "old school" (prior to pa8800/pa8900) machines could rely on
the buss timing to guarantee that coherency arbitration always won
the race with buss arbitration.
The new runway buss is running DDR (double data rate) with both edges
of the clock active. The overall effect of this change is another
gray area in the public documents.
>
> Joel ran a test kernel with a patch to align statically allocated
> locks. It might have run a bit longer than average but there was
> still a softlockup after a few days. So, I don't think the lockup
> is due to the spinlock design per say, although I could easily
> be wrong. I think it's more likely to be something to do with
> interrupt handling. This is suggested by the stack traces which
> often seem to occur in the interrupt return path.
>
There may well be more than one subtle failure involved.
It may not be a single point (spinlocks) failure.
> I've looked at the locking in hpux a bit. As far as I can tell,
> the kernel never really spins. It has code to do pre-arbitration
> and keeps track of tasks and priorities. When a lock is released,
> the code calls into suwaiters to see if the lock should be handed
> over to another task or released. When we just spin, we are relying
> on the bus arbitration to select a winner. So, when we have a
> highly contended lock, it might be possible for a cpu to get locked
> out for sufficient time to cause a softlockup.
>
I never went back to correct the state tables in the document I worked
up to match the most recent code snippets...
I will fix that and then post a link on this list.
Right or wrong - that document gives us the ground work for lock passing
and lock failure recovery without ever having seen HPUX.
I can see where gains could be made in the 4 or more processor case, but
not anything that would help Joel's 2 processor machine.
I still think it will require a good test protocol to find this problem
and I am still stuck on finding a good test protocol.
> Dave
Mike
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [parisc-linux] User space locks -- what's wrong
2006-06-07 12:25 ` Michael S. Zick
@ 2006-06-10 17:41 ` Michael S. Zick
0 siblings, 0 replies; 22+ messages in thread
From: Michael S. Zick @ 2006-06-10 17:41 UTC (permalink / raw)
To: parisc-linux
On Wed June 7 2006 07:25, Michael S. Zick wrote:
> On Tue June 6 2006 23:09, John David Anglin wrote:
> >
> >
> > I've looked at the locking in hpux a bit. As far as I can tell,
> > the kernel never really spins. It has code to do pre-arbitration
> > and keeps track of tasks and priorities. When a lock is released,
> > the code calls into suwaiters to see if the lock should be handed
> > over to another task or released. When we just spin, we are relying
> > on the bus arbitration to select a winner. So, when we have a
> > highly contended lock, it might be possible for a cpu to get locked
> > out for sufficient time to cause a softlockup.
> >
>
> I never went back to correct the state tables in the document I worked
> up to match the most recent code snippets...
>
> I will fix that and then post a link on this list.
>
Document is now updated. Intended to be a continuation of Dave's one
spinlock per cache-line experimental patch.
See:
http://www.morethan.org/parisc/pa-spinlocks.html
http://www.morethan.org/parisc/pa-spinlocks.pdf
>
> Right or wrong - that document gives us the ground work for lock passing
> and lock failure recovery without ever having seen HPUX.
>
Document does not yet have pa-risc examples of lock passing and lock failure
recovery - you need to consult the references made for those at this point.
>
> > Dave
>
> Mike
Mike
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [parisc-linux] User space locks -- what's wrong
2006-06-07 1:30 ` Carlos O'Donell
2006-06-07 4:09 ` John David Anglin
@ 2006-06-11 21:56 ` John David Anglin
2006-06-11 23:20 ` Carlos O'Donell
1 sibling, 1 reply; 22+ messages in thread
From: John David Anglin @ 2006-06-11 21:56 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: parisc-linux
> You've implemented almost exactly what glibc does for pthreads.
> However, glibc uses nanosleep without any adverse effects.
Are you sure? The libgomp test libgomp.fortran/reduction6.f90
times out. It's using pthread_mutex_lock and pthread_mutex_unlock
for locking (there's no futex implementation for parisc-linux).
I see with top:
top - 13:30:57 up 7 days, 22:52, 3 users, load average: 0.00, 0.00, 0.00
Tasks: 73 total, 1 running, 72 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.2% us, 0.3% sy, 0.0% ni, 99.3% id, 0.2% wa, 0.0% hi, 0.0% si
Mem: 8227376k total, 8025664k used, 201712k free, 489404k buffers
Swap: 1367032k total, 0k used, 1367032k free, 3775216k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
...
7430 dave 15 0 8076 988 768 S 0 0.0 0:00.05 reduction6.xg
7431 dave 16 0 8076 988 768 S 0 0.0 0:00.00 reduction6.xg
7432 dave 19 0 8076 988 768 S 0 0.0 0:00.00 reduction6.xg
7433 dave 20 0 8076 988 768 S 0 0.0 0:00.00 reduction6.xg
...
strace indicates that the reduction6.xg processes are mainly calling
sched_yield(), and occassionally nanosleep().
The program doesn't timeout under hpux. I killed the program after 50m
on linux. It appears that we are deadlocking on linux. The time on
a relatively slow hpux system is:
# time ./reduction6.xg
real 0m0.047s
user 0m0.030s
sys 0m0.010s
It appears that the hpux built application never sleeps or calls
sched_yield. Under linux, I see after running a bit the following
backtrace in nanosleep:
Program received signal SIGINT, Interrupt.
0x00032310 in nanosleep ()
(gdb) bt
#0 0x00032310 in nanosleep ()
#1 0x0003189c in __pthread_acquire (spinlock=0x191030) at spinlock.c:716
#2 0x000319d4 in __pthread_alt_unlock (lock=0xbff00d4c) at spinlock.c:527
#3 0x0002ef18 in __pthread_mutex_unlock (mutex=<value optimized out>)
at mutex.c:199
#4 0x00015388 in *_gfortran_st_write_done (dtp=0xbff00aa8)
at ../../../gcc/libgfortran/io/transfer.c:2424
#5 0x000105ac in MAIN__ ()
at /home/dave/gcc-4.2/gcc/libgomp/testsuite/libgomp.fortran/reduction6.f90:10
#6 0x00011e58 in main (argc=<value optimized out>, argv=<value optimized out>)
at ../../../gcc/libgfortran/fmain.c:18
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [parisc-linux] User space locks -- what's wrong
2006-06-11 21:56 ` John David Anglin
@ 2006-06-11 23:20 ` Carlos O'Donell
2006-06-11 23:57 ` John David Anglin
0 siblings, 1 reply; 22+ messages in thread
From: Carlos O'Donell @ 2006-06-11 23:20 UTC (permalink / raw)
To: John David Anglin; +Cc: parisc-linux
On 6/11/06, John David Anglin <dave@hiauly1.hia.nrc.ca> wrote:
> > You've implemented almost exactly what glibc does for pthreads.
> > However, glibc uses nanosleep without any adverse effects.
>
> Are you sure? The libgomp test libgomp.fortran/reduction6.f90
> times out. It's using pthread_mutex_lock and pthread_mutex_unlock
> for locking (there's no futex implementation for parisc-linux).
Can we get a reduced testcase from this?
> strace indicates that the reduction6.xg processes are mainly calling
> sched_yield(), and occassionally nanosleep().
Yes, the core in glibc reads like this:
linuxthreads/spinlock.c (__pthread_acquire):
722 READ_MEMORY_BARRIER();
723
724 while (testandset(spinlock)) {
725 if (cnt < MAX_SPIN_COUNT) {
726 sched_yield();
727 cnt++;
728 } else {
729 tm.tv_sec = 0;
730 tm.tv_nsec = SPIN_SLEEP_DURATION;
731 nanosleep(&tm, NULL);
732 cnt = 0;
733 }
734 }
So you will see "sched_yield" and "nanosleep".
> The program doesn't timeout under hpux. I killed the program after 50m
> on linux. It appears that we are deadlocking on linux. The time on
> a relatively slow hpux system is:
If a child misses a signal and doesn't call __pthread_release, then
the lock is held forever.
In which case switching over to futex's, or even LWS CAS is not going to help.
Truth be told, many applications don't call "__pthread_acquire" like
we do, they use a CAS insn to acquire the lock.
We *could* experiment with turning on HAS_COMPARE_AND_SWAP in
linuxthreads, and using the LWS CAS to implement this.
I'm dying for a testcase...
> It appears that the hpux built application never sleeps or calls
> sched_yield. Under linux, I see after running a bit the following
> backtrace in nanosleep:
Yes, that's an attempt to acquire the lock.
Cheers,
Carlos.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [parisc-linux] User space locks -- what's wrong
2006-06-11 23:20 ` Carlos O'Donell
@ 2006-06-11 23:57 ` John David Anglin
2006-06-12 0:34 ` Carlos O'Donell
0 siblings, 1 reply; 22+ messages in thread
From: John David Anglin @ 2006-06-11 23:57 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: parisc-linux
> On 6/11/06, John David Anglin <dave@hiauly1.hia.nrc.ca> wrote:
> > > You've implemented almost exactly what glibc does for pthreads.
> > > However, glibc uses nanosleep without any adverse effects.
> >
> > Are you sure? The libgomp test libgomp.fortran/reduction6.f90
> > times out. It's using pthread_mutex_lock and pthread_mutex_unlock
> > for locking (there's no futex implementation for parisc-linux).
>
> Can we get a reduced testcase from this?
> We *could* experiment with turning on HAS_COMPARE_AND_SWAP in
> linuxthreads, and using the LWS CAS to implement this.
>
> I'm dying for a testcase...
The testcase is already quite reduced:
! { dg-do run }
integer, dimension (6, 6) :: a
character (36) :: c
integer nthreads
a = 9
nthreads = -1
call foo (a (2:4, 3:5), nthreads)
if (nthreads .eq. 3) then
write (c, '(36i1)') a
if (c .ne. '999999999999966699966699966699999999') call abort
end if
contains
subroutine foo (b, nthreads)
use omp_lib
integer, dimension (3:, 5:) :: b
integer :: err, nthreads
b = 0
err = 0
!$omp parallel num_threads (3) reduction (+:b)
if (any (b .ne. 0)) then
!$omp atomic
err = err + 1
end if
!$omp master
nthreads = omp_get_num_threads ()
!$omp end master
b = 2
!$omp end parallel
if (err .gt. 0) call abort
end subroutine foo
end
I've forgotten all the fortran I ever knew. In any case, I suspect
a lock initialization problem. In the first call into __pthread_acquire
with this particular lock, it's not initialized:
(gdb) p *spinlock
$10 = {lock = {0, 0, 0, 0}} <== we would see some ones if initialized
(gdb) bt
#0 __pthread_acquire (spinlock=0x191030) at spinlock.c:710
#1 0x000319d4 in __pthread_alt_unlock (lock=0x191030) at spinlock.c:527
#2 0x0002ef18 in __pthread_mutex_unlock (mutex=<value optimized out>)
at mutex.c:199
#3 0x00015388 in *_gfortran_st_write_done (dtp=0xbff00aa8)
at ../../../gcc/libgfortran/io/transfer.c:2424
#4 0x000105ac in MAIN__ ()
at /home/dave/gcc-4.2/gcc/libgomp/testsuite/libgomp.fortran/reduction6.f90:10
#5 0x00011e58 in main (argc=<value optimized out>, argv=<value optimized out>)
at ../../../gcc/libgfortran/fmain.c:18
(gdb) p/x *($sp - 0x78)
$11 = 0x191030
So, I believe the value for spinlock in the backtrace. Thus, this is
probably a libgfortran issue.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [parisc-linux] User space locks -- what's wrong
2006-06-11 23:57 ` John David Anglin
@ 2006-06-12 0:34 ` Carlos O'Donell
2006-06-12 0:54 ` John David Anglin
2006-06-12 1:55 ` John David Anglin
0 siblings, 2 replies; 22+ messages in thread
From: Carlos O'Donell @ 2006-06-12 0:34 UTC (permalink / raw)
To: John David Anglin; +Cc: parisc-linux
On 6/11/06, John David Anglin <dave@hiauly1.hia.nrc.ca> wrote:
> (gdb) p *spinlock
> $10 = {lock = {0, 0, 0, 0}} <== we would see some ones if initialized
> So, I believe the value for spinlock in the backtrace. Thus, this is
> probably a libgfortran issue.
That is good news! It's an unfortuante side-effect of our lock code.
Which goes away in NPTL ... thankfully.
Cheers,
Carlos.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [parisc-linux] User space locks -- what's wrong
2006-06-12 0:34 ` Carlos O'Donell
@ 2006-06-12 0:54 ` John David Anglin
2006-06-12 2:27 ` Carlos O'Donell
2006-06-12 1:55 ` John David Anglin
1 sibling, 1 reply; 22+ messages in thread
From: John David Anglin @ 2006-06-12 0:54 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: parisc-linux
> On 6/11/06, John David Anglin <dave@hiauly1.hia.nrc.ca> wrote:
> > (gdb) p *spinlock
> > $10 = {lock = {0, 0, 0, 0}} <== we would see some ones if initialized
> > So, I believe the value for spinlock in the backtrace. Thus, this is
> > probably a libgfortran issue.
In the first call to st_write_done, I see:
(gdb) p *((st_parameter_dt *)$r26)->u.p.current_unit
$38 = {unit_number = -1, s = 0x193248, left = 0x0, right = 0x0, priority = 0,
read_bad = 1, current_record = 1, endfile = NO_ENDFILE, mode = WRITING,
flags = {access = ACCESS_SEQUENTIAL, action = ACTION_READWRITE,
blank = BLANK_NULL, delim = DELIM_NONE, form = FORM_FORMATTED,
is_notpadded = 0, position = POSITION_ASIS, status = STATUS_UNSPECIFIED,
pad = PAD_YES, convert = CONVERT_NATIVE}, recl = 36, last_record = 0,
maxrec = 0, bytes_left = 0, lock = {__m_reserved = 0, __m_count = 0,
__m_owner = 0x0, __m_kind = 0, __m_lock = {__spinlock = {lock = {0, 0, 0,
0}}, __status = 0}}, waiting = 0, closed = 0, ls = 0x0, rank = 0,
file_len = 0, file = 0x0}
The only unit numbers that I see being initialized are 5, 6 and 0.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [parisc-linux] User space locks -- what's wrong
2006-06-12 0:54 ` John David Anglin
@ 2006-06-12 2:27 ` Carlos O'Donell
0 siblings, 0 replies; 22+ messages in thread
From: Carlos O'Donell @ 2006-06-12 2:27 UTC (permalink / raw)
To: John David Anglin; +Cc: parisc-linux
On 6/11/06, John David Anglin <dave@hiauly1.hia.nrc.ca> wrote:
> (gdb) p *((st_parameter_dt *)$r26)->u.p.current_unit
> $38 = {unit_number = -1, s = 0x193248, left = 0x0, right = 0x0, priority = 0,
> read_bad = 1, current_record = 1, endfile = NO_ENDFILE, mode = WRITING,
> flags = {access = ACCESS_SEQUENTIAL, action = ACTION_READWRITE,
> blank = BLANK_NULL, delim = DELIM_NONE, form = FORM_FORMATTED,
> is_notpadded = 0, position = POSITION_ASIS, status = STATUS_UNSPECIFIED,
> pad = PAD_YES, convert = CONVERT_NATIVE}, recl = 36, last_record = 0,
> maxrec = 0, bytes_left = 0, lock = {__m_reserved = 0, __m_count = 0,
> __m_owner = 0x0, __m_kind = 0, __m_lock = {__spinlock = {lock = {0, 0, 0,
> 0}}, __status = 0}}, waiting = 0, closed = 0, ls = 0x0, rank = 0,
> file_len = 0, file = 0x0}
>
> The only unit numbers that I see being initialized are 5, 6 and 0.
The "lock" variable must always be initialized.
The value of __GTHREAD_MUTEX_INIT should be set to PTHREAD_MUTEX_INITIALIZER.
There might be some missing initializers, or memsets, which don't show
problems on i686-pc-linux-gnu, but are invalid things to do on hppa :)
I see that "unit_lock" is initialized properly, without this nothing would work.
There is a bug in "get_internal_unit" where there is a memset of a
"gfc_unit" without a mutex initializer.
Index: libgfortran/io/unit.c
===================================================================
--- libgfortran/io/unit.c (revision 114219)
+++ libgfortran/io/unit.c (working copy)
@@ -376,7 +376,16 @@
}
memset (iunit, '\0', sizeof (gfc_unit));
+#ifdef __GTHREAD_MUTEX_INIT
+ {
+ __gthread_mutex_t tmp = __GTHREAD_MUTEX_INIT;
+ iunit->lock = tmp;
+ }
+#else
+ __GTHREAD_MUTEX_INIT_FUNCTION (&iunit->lock);
+#endif
+
iunit->recl = dtp->internal_unit_len;
/* For internal units we set the unit number to -1.
Please verify.
Cheers,
Carlos.
Cheers,
Carlos.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [parisc-linux] User space locks -- what's wrong
2006-06-12 0:34 ` Carlos O'Donell
2006-06-12 0:54 ` John David Anglin
@ 2006-06-12 1:55 ` John David Anglin
2006-06-12 3:09 ` Carlos O'Donell
1 sibling, 1 reply; 22+ messages in thread
From: John David Anglin @ 2006-06-12 1:55 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: parisc-linux
> That is good news! It's an unfortuante side-effect of our lock code.
> Which goes away in NPTL ... thankfully.
Here's another one (libjava Process_3.exe):
(gdb) bt
#0 0x4005e1f4 in nanosleep () from /lib/libpthread.so.0
#1 0x40059270 in __pthread_timedsuspend_new () from /lib/libpthread.so.0
#2 0x40056414 in pthread_cond_timedwait@GLIBC_2.2 () from /lib/libpthread.so.0
#3 0x41872de8 in _Jv_CondWait (cv=0x402bde20, mu=0x402bde30,
millis=<value optimized out>, nanos=0)
at ../../../gcc/libjava/posix-threads.cc:169
#4 0x4185f3d0 in java::lang::Object::wait (this=0x0, timeout=1000, nanos=0)
at ../../../gcc/libjava/java/lang/natObject.cc:1333
#5 0x4184a48c in java.lang.Object.wait(long)void (this=0x432fd9d0,
timeout=35486947928) at ../../../gcc/libjava/java/lang/Object.java:449
#6 0x41c97ee0 in java.lang.ConcreteProcess$ProcessManager.run()void (
this=0x40536f50) at ConcreteProcess.java:142
#7 0x41864104 in _Jv_ThreadRun (thread=0x40536f50)
at ../../../gcc/libjava/java/lang/natThread.cc:302
#8 0x41872770 in really_start (x=0x401d9830)
at ../../../gcc/libjava/posix-threads.cc:432
#9 0x424d93e0 in GC_start_routine (arg=0x401f6e80)
at ../../../gcc/boehm-gc/pthread_support.c:1191
#10 0x40057498 in pthread_start_thread () from /lib/libpthread.so.0
#11 0x40933754 in clone () from /lib/libc.so.6
#12 0x40933754 in clone () from /lib/libc.so.6
Previous frame identical to this frame (corrupt stack?)
After the testsuite had completed, I noticed that two Process_3 processes
were still running. I attached to both with strace but there wasn't any
syscall activity in either. I then killed the process that top said was
using almost 100% of the cpu with SIGABRT and got a core dump with the
above backtrace. I'm now left with:
dave 7124 1 92 08:13 ? 12:29:14 [Process_3.exe]
>>From past experience, rebooting is the only way to get rid of this
task. This was using a 32-bit c3k kernel (2.6.17-rc3-pa3).
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [parisc-linux] User space locks -- what's wrong
2006-06-12 1:55 ` John David Anglin
@ 2006-06-12 3:09 ` Carlos O'Donell
0 siblings, 0 replies; 22+ messages in thread
From: Carlos O'Donell @ 2006-06-12 3:09 UTC (permalink / raw)
To: John David Anglin; +Cc: parisc-linux
On 6/11/06, John David Anglin <dave@hiauly1.hia.nrc.ca> wrote:
> (gdb) bt
> #0 0x4005e1f4 in nanosleep () from /lib/libpthread.so.0
> #1 0x40059270 in __pthread_timedsuspend_new () from /lib/libpthread.so.0
> #2 0x40056414 in pthread_cond_timedwait@GLIBC_2.2 () from /lib/libpthread.so.0
> #3 0x41872de8 in _Jv_CondWait (cv=0x402bde20, mu=0x402bde30,
> millis=<value optimized out>, nanos=0)
> at ../../../gcc/libjava/posix-threads.cc:169
> #4 0x4185f3d0 in java::lang::Object::wait (this=0x0, timeout=1000, nanos=0)
> at ../../../gcc/libjava/java/lang/natObject.cc:1333
> #5 0x4184a48c in java.lang.Object.wait(long)void (this=0x432fd9d0,
> timeout=35486947928) at ../../../gcc/libjava/java/lang/Object.java:449
> #6 0x41c97ee0 in java.lang.ConcreteProcess$ProcessManager.run()void (
> this=0x40536f50) at ConcreteProcess.java:142
> #7 0x41864104 in _Jv_ThreadRun (thread=0x40536f50)
> at ../../../gcc/libjava/java/lang/natThread.cc:302
> #8 0x41872770 in really_start (x=0x401d9830)
> at ../../../gcc/libjava/posix-threads.cc:432
> #9 0x424d93e0 in GC_start_routine (arg=0x401f6e80)
> at ../../../gcc/boehm-gc/pthread_support.c:1191
> #10 0x40057498 in pthread_start_thread () from /lib/libpthread.so.0
> #11 0x40933754 in clone () from /lib/libc.so.6
> #12 0x40933754 in clone () from /lib/libc.so.6
> Previous frame identical to this frame (corrupt stack?)
The code in __pthread_timedsuspend_new is *very* signal sensitive.
It masks all signals except the restart signal. If this signal is missed, then
the restart never happens.
1377 /* Sleep for the required duration. If woken by a signal,
1378 resume waiting as required by Single Unix Specification. */
1379 if (reltime.tv_sec < 0 || __libc_nanosleep(&reltime, NULL) == 0)
1380 break;
1381 }
It may be that the kernel timer routines are rounding, and we never
finish off that last little bit of time? If you debug this again, it
would be nice to see what the sleep times are in those variables?
Cheers,
Carlos.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <no.id>]
* Re: [parisc-linux] User space locks -- what's wrong
[not found] <no.id>
@ 2006-06-09 0:56 ` John David Anglin
0 siblings, 0 replies; 22+ messages in thread
From: John David Anglin @ 2006-06-09 0:56 UTC (permalink / raw)
To: John David Anglin; +Cc: kyle, parisc-linux
> There definitely are some funky things going on in the kernel.
> For example, if I try to build GCC with 'make -j 4 bootstrap' on
> gsyprf11, about 50% of the time make dies because of a malloc data
> corruption or a shell problem. However, I never see this with
> just 'make bootstrap'.
This is an example:
/home/dave/gcc-4.2/objdir/./prev-gcc/xgcc -B/home/dave/gcc-4.2/objdir/./prev-gcc
/ -B/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/bin/ -c -g -O2 -DIN_GCC -W -
Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-lon
g-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmis
sing-format-attribute -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/
gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/inclu
de -I../../gcc/gcc/../libdecnumber -I../libdecnumber ../../gcc/gcc/c-typeck.
c -o c-typeck.o
/bin/sh: line 6: 24262 Segmentation fault (core dumped) make "DESTDIR=" "RP
ATH_ENVVAR=LD_LIBRARY_PATH" "TARGET_SUBDIR=hppa-linux" "bindir=/home/dave/opt/gn
u/gcc/gcc-4.2.0/bin" "datadir=/home/dave/opt/gnu/gcc/gcc-4.2.0/share" "exec_pref
ix=/home/dave/opt/gnu/gcc/gcc-4.2.0" "includedir=/home/dave/opt/gnu/gcc/gcc-4.2.
0/include" "datarootdir=/home/dave/opt/gnu/gcc/gcc-4.2.0/share" "docdir=/home/da
ve/opt/gnu/gcc/gcc-4.2.0/share/doc" "infodir=/home/dave/opt/gnu/gcc/gcc-4.2.0/in
fo" "htmldir=/home/dave/opt/gnu/gcc/gcc-4.2.0/share/doc" "libdir=/home/dave/opt/
gnu/gcc/gcc-4.2.0/lib" "libexecdir=/home/dave/opt/gnu/gcc/gcc-4.2.0/libexec" "li
spdir=" "localstatedir=/home/dave/opt/gnu/gcc/gcc-4.2.0/var" "mandir=/home/dave/
opt/gnu/gcc/gcc-4.2.0/man" "oldincludedir=/usr/include" "prefix=/home/dave/opt/g
nu/gcc/gcc-4.2.0" "sbindir=/home/dave/opt/gnu/gcc/gcc-4.2.0/sbin" "sharedstatedi
r=/home/dave/opt/gnu/gcc/gcc-4.2.0/com" "sysconfdir=/home/dave/opt/gnu/gcc/gcc-4
.2.0/etc" "tooldir=/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux" "build_tooldir=/
home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux" "target_alias=hppa-linux" "BISON=bis
on" "CC_FOR_BUILD=gcc" "CFLAGS_FOR_BUILD=-g -O2" "CXX_FOR_BUILD=c++" "EXPECT=/ho
me/dave/opt/gnu/bin/expect" "FLEX=flex" "INSTALL=/usr/bin/install -c" "INSTALL_D
ATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_S
CRIPT=/usr/bin/install -c" "LEX=flex" "M4=m4" "MAKE=make" "RUNTEST=runtest" "RUN
TESTFLAGS=" "SHELL=/bin/sh" "YACC=bison -y" "`echo 'ADAFLAGS=' | sed -e s'/[^=][
^=]*=$/XFOO=/'`" "AR_FLAGS=rc" "`echo 'BOOT_ADAFLAGS=' | sed -e s'/[^=][^=]*=$/X
FOO=/'`" "BOOT_CFLAGS=-g -O2" "BOOT_LDFLAGS=" "CFLAGS=-g -O2" "CXXFLAGS=-g -O2"
"LDFLAGS=" "LIBCFLAGS=-g -O2" "LIBCXXFLAGS=-g -O2 -fno-implicit-templates" "STAG
E1_CFLAGS=-g" "STAGE1_LANGUAGES=c,ada" "AR_FOR_TARGET=ar" "AS_FOR_TARGET=as" "CC
_FOR_TARGET=/home/dave/gcc-4.2/objdir/./gcc/xgcc -B/home/dave/gcc-4.2/objdir/./g
cc/ -B/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/bin/ -B/home/dave/opt/gnu/gcc/
gcc-4.2.0/hppa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/i
nclude -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/sys-include" "CFLAGS
_FOR_TARGET=-O2 -g -O2 " "CPPFLAGS_FOR_TARGET=" "CXX_FOR_TARGET=/home/dave/gcc-4
.2/objdir/./gcc/g++ -B/home/dave/gcc-4.2/objdir/./gcc/ -nostdinc++ -L/home/dave
/gcc-4.2/objdir/hppa-linux/libstdc++-v3/src -L/home/dave/gcc-4.2/objdir/hppa-lin
ux/libstdc++-v3/src/.libs -B/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/bin/ -B/
home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/
gcc-4.2.0/hppa-linux/include -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linu
x/sys-include" "CXXFLAGS_FOR_TARGET=-g -O2 -D_GNU_SOURCE" "DLLTOOL_FOR_TARGET=d
lltool" "GCJ_FOR_TARGET=/home/dave/gcc-4.2/objdir/./gcc/gcj -B/home/dave/gcc-4.2
/objdir/./gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/bin/ -B/home/dave/o
pt/gnu/gcc/gcc-4.2.0/hppa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/h
ppa-linux/include -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/sys-inclu
de" "GFORTRAN_FOR_TARGET=/home/dave/gcc-4.2/objdir/./gcc/gfortran -B/home/dave/g
cc-4.2/objdir/./gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/bin/ -B/home/
dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4
.2.0/hppa-linux/include -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/sys
-include" "LD_FOR_TARGET=ld" "LIPO_FOR_TARGET=lipo" "LDFLAGS_FOR_TARGET=" "LIBCF
LAGS_FOR_TARGET=-O2 -g -O2 " "LIBCXXFLAGS_FOR_TARGET=-g -O2 -D_GNU_SOURCE -fno-
implicit-templates" "NM_FOR_TARGET=nm" "OBJDUMP_FOR_TARGET=objdump" "RANLIB_FOR_
TARGET=ranlib" "STRIP_FOR_TARGET=strip" "WINDRES_FOR_TARGET=windres" "`echo 'LAN
GUAGES=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "LEAN=false" "CONFIG_SHELL=/bin/sh" "
MAKEINFO=makeinfo --split-size=5000000 --split-size=5000000 --split-size=5000000
" 'AR=ar' 'AS=as' 'CC=gcc' 'CXX=c++' 'DLLTOOL=dlltool' 'LD=ld' 'LIPO=lipo' 'NM=n
m' 'OBJDUMP=objdump' 'RANLIB=ranlib' 'STRIP=strip' 'WINDRES=windres' CC="${CC}"
CC_FOR_BUILD="${CC_FOR_BUILD}" STAGE_PREFIX=$r/prev-gcc/ CFLAGS="-g -O2" LIBCFLA
GS="-g -O2" LDFLAGS="" "`echo 'ADAFLAGS=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "GCC
_FOR_TARGET= $r/./gcc/xgcc -B$r/./gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-l
inux/bin/ -B/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/lib/ -isystem /home/dave
/opt/gnu/gcc/gcc-4.2.0/hppa-linux/include -isystem /home/dave/opt/gnu/gcc/gcc-4.
2.0/hppa-linux/sys-include" "`echo 'STMP_FIXPROTO=' | sed -e s'/[^=][^=]*=$/XFOO
=/'`" "`echo 'LIMITS_H_TEST=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "`echo 'LIBGCC2_
CFLAGS=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "`echo 'LIBGCC2_DEBUG_CFLAGS=' | sed
-e s'/[^=][^=]*=$/XFOO=/'`" "`echo 'LIBGCC2_INCLUDES=' | sed -e s'/[^=][^=]*=$/X
FOO=/'`" `if [ -f stage_last ]; then echo quickstrap ; else echo all; fi`
make[2]: *** [all-stage2-gcc] Error 139
make[2]: Leaving directory `/home/dave/gcc-4.2/objdir'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/dave/gcc-4.2/objdir'
make: *** [bootstrap] Error 2
make: INTERNAL: Exiting with 1 jobserver tokens available; should be 4!
Wed Jun 7 20:19:18 PDT 2006
>>From /var/log/debug:
Jun 7 20:19:18 gsyprf11 kernel: do_page_fault() pid=24262 command='make' type=1
5 address=0x1118498f
Jun 7 20:19:18 gsyprf11 kernel: vm_start = 0x00048000, vm_end = 0x00607000
Jun 7 20:19:18 gsyprf11 kernel:
Jun 7 20:19:18 gsyprf11 kernel: YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
Jun 7 20:19:18 gsyprf11 kernel: PSW: 00000000000001000000000000001111 Not taint
ed
Jun 7 20:19:18 gsyprf11 kernel: r00-03 0000000000000000 00000000000476e8 00000
00000029b03 00000000bff07800
Jun 7 20:19:18 gsyprf11 kernel: r04-07 000000000009b268 0000000000000000 00000
0000010fe80 00000000000d8680
Jun 7 20:19:18 gsyprf11 kernel: r08-11 00000000000d8680 0000000000000000 00000
0000010fe80 0000000000000000
Jun 7 20:19:18 gsyprf11 kernel: r12-15 000000000009b1f0 0000000000000000 00000
00000000014 0000000000000000
Jun 7 20:19:18 gsyprf11 kernel: r16-19 0000000000000001 0000000000000001 00000
000000476e8 0000000000000000
Jun 7 20:19:18 gsyprf11 kernel: r20-23 00000000001dfca0 0000000000000000 00000
000c0000003 0000000000000000
Jun 7 20:19:18 gsyprf11 kernel: r24-27 0000000000000001 0000000000000016 00000
000001dfca0 00000000000466e8
Jun 7 20:19:18 gsyprf11 kernel: r28-31 0000000011184943 0000000040000003 00000
00003bd6800 0000000003bd6800
Jun 7 20:19:18 gsyprf11 kernel:
Jun 7 20:19:18 gsyprf11 kernel: IASQ: 0000000003bd6800 0000000003bd6800 IAOQ: 0
000000000029aa3 0000000000029aa7
Jun 7 20:19:18 gsyprf11 kernel: IIR: 4b930098 ISR: 0000000003bd6800 IOR: 0
00000001118498f
Jun 7 20:19:18 gsyprf11 kernel: CPU: 1 CR30: 000000001abb0000 CR31: 0
000000000008020
Jun 7 20:19:18 gsyprf11 kernel: ORIG_R28: 0000000000000000
Jun 7 20:19:18 gsyprf11 kernel: IAOQ[0]: 0x29aa3
Jun 7 20:19:18 gsyprf11 kernel: IAOQ[1]: 0x29aa7
Jun 7 20:19:18 gsyprf11 kernel: RP(r2): 0x29b03
dave@hiauly6:~/opt/gnu/bin$ disasm 0x4b930098
0: 4b 93 00 98 ldw 4c(ret0),r19
(gdb) disass 0x29a90 0x29ab0
Dump of assembler code from 0x29a90 to 0x29ab0:
0x00029a90 <close_stdout+25828>: copy ret0,r20
0x00029a94 <close_stdout+25832>: ldw 48(r20),ret0
0x00029a98 <close_stdout+25836>: cmpiclr,<> 0,ret0,r0
0x00029a9c <close_stdout+25840>: copy r20,ret0
0x00029aa0 <close_stdout+25844>: ldw 4c(ret0),r19
%ret0 is both misaligned and appears outside the VM range for the application.
The backtrace isn't particularly enlightening (need debug version of make).
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <119aab440606111942o1be5e11bw6ede4fa941f01778@mail.gmail.com>]
* Re: [parisc-linux] User space locks -- what's wrong
[not found] <119aab440606111942o1be5e11bw6ede4fa941f01778@mail.gmail.com>
@ 2006-06-12 3:03 ` John David Anglin
2006-06-12 3:13 ` Carlos O'Donell
0 siblings, 1 reply; 22+ messages in thread
From: John David Anglin @ 2006-06-12 3:03 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: parisc-linux
> However, the mutex objects look like they are being cached? There
> could be a scenario where an allocated and locked mutex is put back in
> the cache, such a mutex cannot be cleaned without resetting with
> __PTHREAD_MUTEX_INITIALIZER.
Hmmm, that reminds me that there is this config variable in configure.host,
'slow_pthread_self'.
# slow_pthread_self The synchronization code should try to avoid
# pthread_self calls by caching thread IDs in a hashtable
There's also 'enable_hash_synchronization_default'.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [parisc-linux] User space locks -- what's wrong
2006-06-12 3:03 ` John David Anglin
@ 2006-06-12 3:13 ` Carlos O'Donell
2006-06-12 3:19 ` John David Anglin
2006-06-12 6:01 ` Grant Grundler
0 siblings, 2 replies; 22+ messages in thread
From: Carlos O'Donell @ 2006-06-12 3:13 UTC (permalink / raw)
To: John David Anglin; +Cc: parisc-linux
On 6/11/06, John David Anglin <dave@hiauly1.hia.nrc.ca> wrote:
> > However, the mutex objects look like they are being cached? There
> > could be a scenario where an allocated and locked mutex is put back in
> > the cache, such a mutex cannot be cleaned without resetting with
> > __PTHREAD_MUTEX_INITIALIZER.
>
> Hmmm, that reminds me that there is this config variable in configure.host,
> 'slow_pthread_self'.
>
> # slow_pthread_self The synchronization code should try to avoid
> # pthread_self calls by caching thread IDs in a hashtable
>
> There's also 'enable_hash_synchronization_default'.
Reading the thread register is a single mfctl, I don't know if that is
considered slow?
Cheers,
Carlos.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [parisc-linux] User space locks -- what's wrong
2006-06-12 3:13 ` Carlos O'Donell
@ 2006-06-12 3:19 ` John David Anglin
2006-06-12 6:01 ` Grant Grundler
1 sibling, 0 replies; 22+ messages in thread
From: John David Anglin @ 2006-06-12 3:19 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: parisc-linux
> > # slow_pthread_self The synchronization code should try to avoid
> > # pthread_self calls by caching thread IDs in a hashtable
> >
> > There's also 'enable_hash_synchronization_default'.
>
> Reading the thread register is a single mfctl, I don't know if that is
> considered slow?
Looks like it's the later parameter that affects lock caching:
# Should we use hashtable-based synchronization?
# Currently works only for Linux X86/ia64
# Typically faster and more space-efficient
AC_ARG_ENABLE(hash-synchronization,
AS_HELP_STRING([--enable-hash-synchronization],
[use global hash table for monitor locks]))
I'll try turning this off.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [parisc-linux] User space locks -- what's wrong
2006-06-12 3:13 ` Carlos O'Donell
2006-06-12 3:19 ` John David Anglin
@ 2006-06-12 6:01 ` Grant Grundler
2006-06-12 15:31 ` Carlos O'Donell
1 sibling, 1 reply; 22+ messages in thread
From: Grant Grundler @ 2006-06-12 6:01 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: John David Anglin, parisc-linux
On Sun, Jun 11, 2006 at 11:13:33PM -0400, Carlos O'Donell wrote:
> Reading the thread register is a single mfctl, I don't know if that is
> considered slow?
I believe it depends on the source of the "Move From".
But I can't find a table with timing info. (e.g. mfctl CR16).
I did find this bit though:
| Most control operations (the "light weight" control ops) are
| handled by a mechanism that is very similar to the way that C/B
| dependencies are handled. The major differences are that there
| are no control rename registers, and there is no bypassing.
| Thus, an instruction that is dependent on a control op will not
| be able to execute until the control op retires.
...
"Heavy Weight" control ops are the ones where the instruction execution
is serialized completely.
hth,
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [parisc-linux] User space locks -- what's wrong
2006-06-12 6:01 ` Grant Grundler
@ 2006-06-12 15:31 ` Carlos O'Donell
0 siblings, 0 replies; 22+ messages in thread
From: Carlos O'Donell @ 2006-06-12 15:31 UTC (permalink / raw)
To: Grant Grundler; +Cc: John David Anglin, parisc-linux
On 6/12/06, Grant Grundler <grundler@parisc-linux.org> wrote:
> On Sun, Jun 11, 2006 at 11:13:33PM -0400, Carlos O'Donell wrote:
> > Reading the thread register is a single mfctl, I don't know if that is
> > considered slow?
>
> I believe it depends on the source of the "Move From".
> But I can't find a table with timing info. (e.g. mfctl CR16).
The thread register is CR27, the code to read the value is:
54 static inline struct _pthread_descr_struct * __get_cr27(void)
55 {
56 long cr27;
57 asm ("mfctl %%cr27, %0" : "=r" (cr27) : );
58 return (struct _pthread_descr_struct *) cr27;
59 }
Cheers,
Carlos.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2006-06-12 15:31 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-06-04 23:55 [parisc-linux] User space locks -- what's wrong John David Anglin
2006-06-05 14:40 ` Kyle McMartin
2006-06-05 16:49 ` John David Anglin
2006-06-05 17:40 ` James Bottomley
2006-06-07 1:30 ` Carlos O'Donell
2006-06-07 4:09 ` John David Anglin
2006-06-07 12:25 ` Michael S. Zick
2006-06-10 17:41 ` Michael S. Zick
2006-06-11 21:56 ` John David Anglin
2006-06-11 23:20 ` Carlos O'Donell
2006-06-11 23:57 ` John David Anglin
2006-06-12 0:34 ` Carlos O'Donell
2006-06-12 0:54 ` John David Anglin
2006-06-12 2:27 ` Carlos O'Donell
2006-06-12 1:55 ` John David Anglin
2006-06-12 3:09 ` Carlos O'Donell
[not found] <no.id>
2006-06-09 0:56 ` John David Anglin
[not found] <119aab440606111942o1be5e11bw6ede4fa941f01778@mail.gmail.com>
2006-06-12 3:03 ` John David Anglin
2006-06-12 3:13 ` Carlos O'Donell
2006-06-12 3:19 ` John David Anglin
2006-06-12 6:01 ` Grant Grundler
2006-06-12 15:31 ` Carlos O'Donell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox