当我们在 NUMA 系统上工作时，内存可以相对于当前 NUMA 节点是本地或远程的。为了使内存更加本地化，有一个“first-touch”策略（默认内存到节点绑定策略）： http: //lse.sourceforge.net/numa/status/description.html
默认内存绑定 重要的是，用户程序的内存分配在靠近包含运行它们的 CPU 的节点上。因此，默认情况下，页面错误由包含页面错误 CPU 的节点的内存来满足。因为第一个接触页面的 CPU 将是错误进入页面的 CPU，所以这个默认策略称为“第一次接触”。
默认策略称为首次接触。在此策略下，首先接触（即写入或读取）内存页面的进程会导致该页面在运行该进程的节点中分配。此策略适用于顺序程序和许多并行程序。
还有一些其他的非本地政策。还有一个函数要求将内存段显式移动到某个 NUMA 节点。
但有时（在单个应用程序的许多线程的上下文中）拥有“下一次接触”策略可能很有用：调用一些函数来“取消绑定”一些内存区域（最多 100 s MB）与一些数据并重新应用“第一次接触” - 这个区域上的类似处理程序，它将在下一次触摸（读取或写入）时将页面迁移到访问线程的 numa 节点。
当有大量数据要由许多线程处理并且有不同的访问该数据的模式时（例如，第一阶段 - 通过线程按列拆分 2D 数组；第二阶段 - 按行拆分相同的数据），此策略很有用。
自 9 以来，Solaris 通过带有 MADV_ACCESS_LWP 标志的 madvice 支持此类策略
https://cims.nyu.edu/cgi-systems/man.cgi?section=3C&topic=madvise
MADV_ACCESS_LWP 告诉内核下一个接触指定地址范围的 LWP 将最频繁地访问它，因此内核应该尝试为这个范围和 LWP 相应地分配内存和其他资源。
有（2009 年 5 月）名为“affinity-on-next-touch”的 Linux 内核补丁， http: //lwn.net/Articles/332754/（线程），但据我了解，它未被主线接受，不是它？
还有 Lee Schermerhorn 的“migrate_on_fault”补丁 http://free.linux.hp.com/~lts/Patches/PageMigration/。
所以，问题是：在当前的 vanilla Linux 内核或一些主要的分支中，如 RedHat linux 内核或 Oracle linux 内核，NUMA 是否有一些下一个接触？