{"id":3752,"date":"2014-06-03T12:17:49","date_gmt":"2014-06-03T02:17:49","guid":{"rendered":"https:\/\/www.flamingspork.com\/blog\/?p=3752"},"modified":"2014-06-03T12:03:14","modified_gmt":"2014-06-03T02:03:14","slug":"mysql-5-6-on-power-patch-available","status":"publish","type":"post","link":"https:\/\/www.flamingspork.com\/blog\/2014\/06\/03\/mysql-5-6-on-power-patch-available\/","title":{"rendered":"MySQL 5.6 on POWER (patch available)"},"content":{"rendered":"

The following sentence is brought to you by IBM Legal. The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.<\/p>\n

Okay, now that is out of the way….<\/p>\n

If you’re the kind of person who follows the MySQL<\/a> bugs<\/a> database<\/a> closely or subscribes to the MySQL Internals<\/a> mailing list, you may have worked out that I’ve spent a small amount of time poking at MySQL on modern POWER systems.<\/p>\n

Unlike Intel CPUs, POWER CPUs require explicit memory barriers to synchronize memory state between different CPUs. This means that when you’re implementing synchronization primitives, you have one extra thing to get right.<\/p>\n

Luckily, if you use straight pthread mutexes, this is already taken care of. Unluckily, there are some optimizations in MySQL that don’t use straight pthread mutexes and so may be problematic on non-Intel CPUs. A few of these issues have sneaked into MySQL over the past few years. The most problematic area was around the optimized mutexes in InnoDB (you can use the pthread_mutex fallback code, but it’s less performant).<\/p>\n

Luckily, I both knew where to look and there are good asserts throughout InnoDB code to help spot any other areas that I may not have initially thought of to look at. Coding defensively with a good amount of asserts is a good thing<\/strong>.<\/p>\n

After not too much work, I have a set of patches that I’m fairly confident is correct and performs near as well as possible. Initially, I had a different patch that used heavyweight memory barriers in a lot of places, but big kudos to Yasufumi for posting a better patch than mine to bug 47213<\/a> – using the lighter weight barriers gives a decent performance boost.<\/p>\n

One of the key patches is in the InnoDB mutex code to change the thread priority – i.e. a POWER equivalent to the x86 pause instruction. These are hints to the CPU that the thread being executed is in a spinloop and CPU resources should be allocated to other threads to make betterr forward progress.<\/p>\n

After dragging Anton<\/a> in to have a look and a think, this code may have motivated him to have a go at getting kernel support for adaptive mutexes, thus removing the need for this spin\/sleep\/yield\/eep loop in InnoDB (at least on Linux).<\/p>\n

So… I’ve spent the appropriate time filing bugs in the MySQL bug tracker for the things I’ve found. Feel free to track them yourself, they are:<\/p>\n