Thanks!This sounds interesting and useful, a good project.
It'll need to be much more clearly defined though, unless you expect a student
to fill in all blanks (it's a valid assumption, but, in my opinion, a bit
optimistic).

A couple of thoughts:

• What kind of meaningful configuration? Example?
• pinned SQL threads - ok, and any thread local allocation should use the
  appropriate NUMA node.

Implementation plan from a configuration point of view.

• numa=off,on - this will be a read only system variable and a mysqld start option to enable numa which defaults to off
• numa_scheduler= {user,host,db}

  - this will be one or more of these elements by which the server will allocate a node.

• numa_scheduler_host_mask = a CIDR that is applied to the host for the purposes of numa scheduling (IPv6?)
• thread_handling=one-thread-per-connection - With thread cache entries - threads will have a numa node node assigned. Threads with an desired numa affinity will be used before altering the affinity of an existing thread
• thread_handling=pool-of-threads (Unix only) - thread_pool_size will be limited to multiples the number of numa nodes. Each thread has affinity to the CPUs corresponding to the numa node.
• innodb_buffer_pool_instances - will start of with being one per node only when numa is enabled - can expand if time permits
• innodb_read_io_threads and innodb_write_io_threads - default to two threads per nodes and both affinity bound.
• innodb_page_cleaners one per number node

Best guesses so far:

• The mysqld client thread loop will be bound to a node as will innodb_encryption_threads

Unsure how to handle

• slave_parallel_threads - mapping per domain, per (master) connection or just group them
• innodb_ft_sort_pll_degree
• innodb_mtflush_threads
• innodb_purge_threads

Threads generally - will have sched_setaffinity/SetThreadAffinityMask set to the cpu set corresponding to the numa node.

NUMA implementation will be abstracted and support Windows equivalent NUMA functions - https://msdn.microsoft.com/en-us/library/windows/desktop/aa363804(v=vs.85).aspx

Eventually - persistent table of mappings

Out of scope:

• MyISAM - key cache segments maybe eventually
• All other storage engines

Eventually we'll have to bind table cache instances and MDL instances (not yet implemented) to NUMA nodes. As well as PFS counters and some status variables. Please keep this in mind.

Thanks svoj. All tips gratefully received.

GSOC approved with Sumit Lakra as the student. Mentors: jplindst and me.

Tip from irc worthy of consideration at some stage: memory engine is a good candidate

futex2 - designed for numa

innodb_mtflush_threads and its replacement were removed, and in MDEV-23855 the single page cleaner thread was simplified. MDEV-16264 refactored many of the InnoDB background threads into tasks.

I think that it would be very challenging make all users of the buffer pool aware of NUMA (say, actively migrate execution threads to the NUMA node that owns most of the data that is likely to be addressed). I wonder if it could make sense to partition the buf_pool.page_hash in such a way that pages would be mapped to NUMA nodes by some simple formula like page_id.raw()%N_NUMA. All entries of a buf_pool_numa[i].page_hash would point to buffer pool block descriptors and blocks that reside in that NUMA node. I think that we should keep a global buf_pool.LRU and buf_pool.flush_list in any case.