Bug #72807 Set thread priority in my_pthread_fastmutex_lock

• Submitted: 30 May 2014 6:53
• Modified: 29 Apr 2015 0:13
• Reporter: Stewart Smith
• Status: Closed
• Category: MySQL Server: Locking
• Severity: S5 (Performance)
• Version: 5.7.7
• OS: Any
• CPU Architecture: Any
• Tags: mysys, PowerPC

[30 May 2014 6:53] Stewart Smith

Description:
Similar to the PAUSE instruction on x86 (which is missing here too, see http://bugs.mysql.com/bug.php?id=72806 ) the POWER Architecture provides CPU instructions to give the hint to the CPU that you're in a spinloop and that other threads should be given priority over CPU resources.

On POWER this takes the form of setting the thread priority with special forms of no-op instructions.

How to repeat:
Code analysis and profiling!

Suggested fix:
attached patch:

--- mysql-5.7.4-m14.orig/mysys/thr_mutex.c
+++ mysql-5.7.4-m14/mysys/thr_mutex.c
@@ -400,9 +400,16 @@ int my_pthread_fastmutex_lock(my_pthread
 
     if (res != EBUSY)
       return res;
-
+#ifdef __powerpc__
+    /* Set low thread priority while spinning */
+    asm volatile ("or 1,1,1");
+#endif
     mutex_delay(maxdelay);
     maxdelay += park_rng(mp) * MY_PTHREAD_FASTMUTEX_DELAY + 1;
+#ifdef __powerpc__
+    /* return to normal thread priority after spinning */
+    asm volatile ("or 2,2,2");
+#endif
   }
   return pthread_mutex_lock(&mp->mutex);
 }

[30 May 2014 6:54] Stewart Smith

set thread priority in my_pthread_fastmutex_lock spin

(*) I confirm the code being submitted is offered under the terms of the OCA, and that I am authorized to contribute it.

Contribution: thr-mutex-power.patch (text/x-patch), 669 bytes.

[30 May 2014 6:57] Stewart Smith

For 5.6, see http://bugs.mysql.com/bug.php?id=72754

[30 May 2014 8:36] MySQL Verification Team

Hello Stewart,

Thank you for the report and contribution.

Thanks,
Umesh

[13 Nov 2014 6:24] Stewart Smith

I seem to have by accident filed http://bugs.mysql.com/bug.php?id=72805 which is a duplicate of this one, but with a better patch (IMHO) and a better explanation.

I'm not sure if Locking is a better category for this bug or not...

[10 Apr 2015 7:56] Stewart Smith

This code should die. the "fastmutex" implementation is no longer fast on any modern CPU. Use libc, it's a lot better than this code. a *LOT*

[10 Apr 2015 9:10] Ståle Deraas

Posted by developer:
 
Stewart, thanks for your confirmation that you do not see any performance gains with this code. We have not seen any gains in our latest tests as well, and are happy to see that you see the same. So we will prefer to remove this and also then not do anything with your contribution to this code.

[29 Apr 2015 0:13] Paul DuBois

Noted in 5.7.8 changelog.

The so-called "fast mutex" code has been removed from the server
sources. It provides no measurable benefit, complicates the code, and
is problematic for certain architectures such as POWER8. The
(undocumented) WITH_FAST_MUTEXES CMake option has also been removed.