lkml.org 
[lkml]   [2003]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [Linux-ia64] Re: web page on O(1) scheduler
Date
Pthread_spin_lock() under the NPTL version in RH9 does basically what my custom locks do in the uncontested case, aside from the function call.  But remember that this began with a discussion about whether it was reasonable for user locking code to explicitly yield rather than relying on pthreads to suspend the thread.  I don't think pthread_spin_lock is relevant in this context, for two reasons:

1) At least the RH9 version of pthread_spin_lock in NPTL literally spins and makes no attempt to yield or block. This only makes sense at user level if you are 100% certain that the processors won't be overcommitted. Otherwise there is little to be lost by blocking once you have spun for sufficiently long. You could use pthread_spin_trylock and block explicitly, but that gets us back to custom blocking code.

2) AFAICT, pthread_spin_lock is currently a little too bleeding edge to be widely used. I tried to time it, but failed. Pthread.h doesn't include the declaration for pthread_spin_lock_t by default, at least not yet. It doesn't seem to have a Linux man page, yet. I tried to define the magic macro to get it declared, but that broke something else.

Hans

> -----Original Message-----
> From: Davide Libenzi [mailto:davidel@xmailserver.org]
> Sent: Friday, May 23, 2003 11:05 AM
> To: Boehm, Hans
> Cc: 'Arjan van de Ven'; Hans Boehm; MOSBERGER, DAVID
> (HP-PaloAlto,unix3); Linux Kernel Mailing List;
> linux-ia64@linuxia64.org
> Subject: RE: [Linux-ia64] Re: web page on O(1) scheduler
>
>
> On Fri, 23 May 2003, Boehm, Hans wrote:
>
> > Sorry about the typo and misnaming for the test program. I
> attached the correct version that prints the right labels.
> >
> > The results I posted did not use NPTL. (Presumably OpenMP
> wasn't targeted at NPTL either.) I don't think that NPTL has
> any bearing on the underlying issues that I mentioned, though
> path lengths are probably a bit shorter. It should also
> handle contention substantially better, but that wasn't tested.
> >
> > I did rerun the test case on a 900 MHz Itanium 2 machine
> with a more recent Debian installation with NPTL. I get
> 200msecs (20nsecs/iter) with the custom lock, and 768 for
> pthreads. (With static linking that decreases to 658 for
> pthreads.) Pthreads (and/or some of the other
> infrastructure) is clearly getting better, but I don't think
> the difference will disappear.
>
> To make things more fair you should test against pthread
> spinlocks. Also,
> for tight loops like that, even an extra call deep level
> (that pthread is
> likely to do) is going to matter.
>
>
>
> - Davide
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:35    [W:0.037 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site