错误共享和128字节对齐/填充

False sharing and 128-byte alignment/padding(错误共享和128字节对齐/填充)

本文介绍了错误共享和128字节对齐/填充的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在研究无锁/无等待算法时,我偶然发现了false sharing问题。深入研究后,我找到了Folly的源代码(Facebook的C++库),更具体地说,找到了header file和FOLLY_ALIGN_TO_AVOID_FALSE_SHARING宏的定义(当前在第130行)。乍一看,最让我惊讶的是值:128(即:代替64).

/// An attribute that will cause a variable or field to be aligned so that
/// it doesn't have false sharing with anything at a smaller memory address.
#define FOLLY_ALIGN_TO_AVOID_FALSE_SHARING __attribute__((__aligned__(128)))

AFAIK,现代CPU上的缓存块是64字节长,实际上,到目前为止,我在这个问题上找到的所有资源,包括来自英特尔的this article,都谈到了64字节对齐填充,以帮助解决错误共享问题。

尽管如此,Facebook的人员仍然会在需要时将其类成员对齐并填充到128个字节。然后我在FOLLY_ALIGN_TO_AVOID_FALSE_SHARING的定义上面找到了一个解释的开头:

enum {
    /// Memory locations on the same cache line are subject to false
    /// sharing, which is very bad for performance.  Microbenchmarks
    /// indicate that pairs of cache lines also see interference under
    /// heavy use of atomic operations (observed for atomic increment on
    /// Sandy Bridge).  See FOLLY_ALIGN_TO_AVOID_FALSE_SHARING
    kFalseSharingRange = 128
};

虽然它给了我更多的细节,但我仍然觉得我需要一些洞察力。我很好奇,在大量使用原子操作的情况下,连续缓存行的同步或它们上的任何rmw操作如何会相互干扰有人能告诉我这是怎么发生的吗?

推荐答案

正如汉斯在评论中指出的,有关这方面的一些信息可以在关于英特尔酷睿微体系结构的3.7.3"二级高速缓存硬件预取"部分"Intel® 64 and IA-32 architectures optimization reference manual"中找到:

"Streamer-将数据或指令从内存加载到二级缓存。要使用Streamer,请将数据或指令组织成128字节的块,并按128字节对齐。第一次访问此挡路中位于内存中的两条缓存线之一时,会触发Streamer预取该对线。"

这篇关于错误共享和128字节对齐/填充的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持编程学习网!

本文标题为:错误共享和128字节对齐/填充

基础教程推荐