innodb_numa_interleave=1, use numa numa_get_mems_allowed

[grooverdan]

Using numa_all_nodes_ptr was excessively optimistic. Due to
constraints in systemd, containers or otherwise mysqld could of been
limited to a smaller set of cpus. Use the numa_get_mems_allowed
library function to see what we can interleave between before doing
so. This prevents repetitive errors "mbind: Invalid argument".

[grooverdan]

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

[mysql-oca-bot]

Hi, thank you for your contribution. Please confirm this code is submitted under the terms of the OCA (Oracle's Contribution Agreement) you have previously signed by cutting and pasting the following text as a comment:
"I confirm the code being submitted is offered under the terms of the OCA, and that I am authorized to contribute it."
Thanks

[mysql-oca-bot]

Hi, thank you for your contribution. Your code has been assigned to an internal queue. Please follow
bug http://bugs.mysql.com/bug.php?id=85932 for updates.
Thanks

[akopytov]

I wonder if this change was really necessary. I've been unsuccessfully trying to create a test case for this fix, and it looks like setting up the environment where this fix would make a difference is non-trivial.

At least with the modern kernel and libnuma, both numa_all_nodes_ptr and numa_get_mems_allowed() use the same source about the allowed memory nodes: the mems_allowed member of the current task's task_struct. The only difference between them is that numa_all_nodes_ptr is initialized once when the process is started by reading /proc/self/status (which reads task_struct::mems_allowed under the hood) , and numa_get_mems_allowed() gets the current set of allowed nodes via get_mempolicy(..., MPOL_F_MEMS_ALLOWED) (which, again, returns current->mems_allowed).

So the only case where this would matter is when a cpuset is changed to a different mems_allowed value between the moments when mysqld is started and the buffer pool is initialized/resized.

Does this fix target those specific cases, or I am missing something?