From: Maxim Kuvyrkov <maxim_kuvyrkov@mentor.com>
To: "Joseph S. Myers" <joseph@codesourcery.com>
Cc: GLIBC Devel <libc-alpha@sourceware.org>, <libc-ports@sourceware.org>
Subject: [PATCH] Optimize libc_lock_lock for MIPS XLP.
Date: Thu, 14 Jun 2012 05:04:00 -0000 [thread overview]
Message-ID: <FC4EF172-B43E-4298-A2E9-681FA28650DB@mentor.com> (raw)
These two patches (libc part and ports part) optimize libc_lock_lock() macro that GLIBC uses for locking internally to take advantage of fetch_and_add instruction that is available as an extension on certain processors, e.g., MIPS-architecture XLP.
The libc_lock_lock macros implement boolean lock: 0 corresponds to unlocked state and non-zero corresponds to locked state. It is, therefore, possible to use fetch_and_add semantics to acquire lock in libc_lock_lock. For XLP this translates to a single LDADD instruction. This optimization allows architectures that can perform fetch_and_add faster than compare_and_exchange, such situation is indicated by defining the new macro "lll_add_lock".
The unlocking counterpart doesn't require any change as it is already uses plain atomic_exchange operation, which, incidentally, also supported on XLP as a single instruction.
Tested on XLP with no regressions. OK to apply once 2.16 branches off?
Thank you,
--
Maxim Kuvyrkov
Mentor Graphics
2012-06-15 Tom de Vries <vries@codesourcery.com>
Maxim Kuvyrkov <maxim@codesourcery.com>
libc/
* nptl/sysdeps/pthread/bits/libc-lockP.h (__libc_lock_lock): Use
lll_add_lock when it is available.
ports/
* sysdeps/unix/sysv/linux/mips/nptl/lowlevellock.h (__lll_add_lock,)
(lll_add_lock): Define.
---
nptl/sysdeps/pthread/bits/libc-lockP.h | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/nptl/sysdeps/pthread/bits/libc-lockP.h b/nptl/sysdeps/pthread/bits/libc-lockP.h
index 0ebac91..58d8366 100644
--- a/nptl/sysdeps/pthread/bits/libc-lockP.h
+++ b/nptl/sysdeps/pthread/bits/libc-lockP.h
@@ -176,8 +176,14 @@ typedef pthread_key_t __libc_key_t;
/* Lock the named lock variable. */
#if !defined NOT_IN_libc || defined IS_IN_libpthread
-# define __libc_lock_lock(NAME) \
+# if defined lll_add_lock
+/* lll_add_lock is faster, so use it when it's available. */
+# define __libc_lock_lock(NAME) \
+ ({ lll_add_lock (NAME, LLL_PRIVATE); 0; })
+# else
+# define __libc_lock_lock(NAME) \
({ lll_lock (NAME, LLL_PRIVATE); 0; })
+# endif
#else
# define __libc_lock_lock(NAME) \
__libc_maybe_call (__pthread_mutex_lock, (&(NAME)), 0)
--
1.7.4.1
---
sysdeps/unix/sysv/linux/mips/nptl/lowlevellock.h | 23 ++++++++++++++++++++-
1 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/sysdeps/unix/sysv/linux/mips/nptl/lowlevellock.h b/sysdeps/unix/sysv/linux/mips/nptl/lowlevellock.h
index 88b601e..bbe9ea7 100644
--- a/sysdeps/unix/sysv/linux/mips/nptl/lowlevellock.h
+++ b/sysdeps/unix/sysv/linux/mips/nptl/lowlevellock.h
@@ -1,5 +1,4 @@
-/* Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008,
- 2009 Free Software Foundation, Inc.
+/* Copyright (C) 2003-2012 Free Software Foundation, Inc.
This file is part of the GNU C Library.
The GNU C Library is free software; you can redistribute it and/or
@@ -172,6 +171,26 @@ extern int __lll_robust_lock_wait (int *futex, int private) attribute_hidden;
}))
#define lll_lock(futex, private) __lll_lock (&(futex), private)
+#if defined(_MIPS_ARCH_XLP)
+/* XLP has a dedicated exchange_and_add instruction, which is significantly
+ faster than ll/sc and doesn't require explicit syncs.
+ As atomic.h currently only supports a full-barrier atomic_exchange_and_add,
+ using a full-barrier operation instead of an acquire-barrier operation is
+ not beneficial for MIPS in general.
+ Limit this optimization to XLP for now. */
+#define __lll_add_lock(futex, private) \
+ ((void) ({ \
+ int *__futex = (futex); \
+ if (__builtin_expect (atomic_exchange_and_add (__futex, 1), 0)) \
+ { \
+ if (__builtin_constant_p (private) && (private) == LLL_PRIVATE) \
+ __lll_lock_wait_private (__futex); \
+ else \
+ __lll_lock_wait (__futex, private); \
+ } \
+ }))
+#define lll_add_lock(futex, private) __lll_add_lock (&(futex), private)
+#endif
#define __lll_robust_lock(futex, id, private) \
({ \
--
1.7.4.1
next reply other threads:[~2012-06-14 5:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-14 5:04 Maxim Kuvyrkov [this message]
2012-06-14 12:39 ` Chris Metcalf
2012-06-15 1:21 ` Maxim Kuvyrkov
2012-06-15 2:44 ` Chris Metcalf
2012-06-15 2:50 ` Maxim Kuvyrkov
2012-06-27 21:45 ` Maxim Kuvyrkov
2012-06-28 17:30 ` Chris Metcalf
2012-07-06 19:42 ` Tom de Vries
2012-08-14 4:00 ` Maxim Kuvyrkov
2012-08-14 19:33 ` Chris Metcalf
2012-08-14 21:30 ` Maxim Kuvyrkov
2012-08-14 21:40 ` Joseph S. Myers
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=FC4EF172-B43E-4298-A2E9-681FA28650DB@mentor.com \
--to=maxim_kuvyrkov@mentor.com \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=libc-ports@sourceware.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).