ZONE_PADDING 作用疑问

lovegq

struct zone 用 ZONE_PADDING 分隔成几个部分,其中 zone->lock 和 zone->lru_lock 分在不同的cache line
深入linux内核架构说，“确保每个自旋锁都处于自身的缓冲行中” 可以提高性能.
哪位 大牛 能给小弟说说， 这怎么就能提高性能了
尤其是 一个大结构体，里面好几个锁, 中间填充填充,让每个锁处在不同的cache line上
这样的做法，究竟是怎么提高性能的？

瀚海书香

回复 1# lovegq

struct zone 用 ZONE_PADDING 分隔成几个部分,其中 zone->lock 和 zone->lru_lock 分在不同的cache line
深入linux内核架构说，“确保每个自旋锁都处于自身的缓冲行中” 可以提高性能.
哪位 大牛 能给小弟说说， 这怎么就能提高性能了
尤其是 一个大结构体，里面好几个锁, 中间填充填充,让每个锁处在不同的cache line上
这样的做法，究竟是怎么提高性能的？

zone->lock和zone->lru_lock经常被访问。如果这两个映射到同一个缓存行，那么就可能会出现
zone->lock 放到cache中，这个时候马上要访问zone->lru_lock，由于zone->lru_lock也是映射到这个cache line上，那么就会把zone->lock从cache中移除，
将zone->lru_lock放到cache中，这样就会导致cache频繁的换入换出，降低了性能。

   

lovegq

zone->lock和zone->lru_lock经常被访问。如果这两个映射到同一个缓存行，那么就可能会出现
zone->lock 放到cache中，这个时候马上要访问zone->lru_lock，由于zone->lru_lock也是映射到这个cache line上，那么就会把zone->lock从cache中移除，
将zone->lru_lock放到cache中，这样就会导致cache频繁的换入换出，降低了性能。

嗯，有点儿明白了。如果zone->lock 和 zone-lru_lock都 "映射" 到同一个缓存行中,确实可能这样。
但是，"映射" 这个词太虚了,
假设 cache line 是64字节
难道我把zone->lock放在第一个64字节中，然后中间填充填充,zone->lru_lock放在第二个64字节中
就能保证 这2个64的line，不会"映射"到同一行?? 这个太玄幻了吧

而且，我感觉，好像把它俩 都塞到同一个64字节当中，不就永远都在同一个cache line中了嘛，何必非要分开?

lovegq

好吧，我短路了，书看的不仔细
第二个问题，我自己想明白了，
这2个锁，分管不同的区域，它俩 + 它俩要锁的东西 一个cache line肯定装不下，估计是为了一次只加载一个cache line,所以要分开塞

第一个问题，cache line 什么全相联，8路相联的 没学好，忘的差不多了
难道，前后挨着的2个64字节，可以保证不会“映射”到同一个cache line当中？？

liuiang

对于一些老的设计，前后挨着一定不会映射到同一个cache line，对于现在的一些设计，有可能，但是概率极低。退一步，就算映射到一个line也无所谓，毕竟还有那么多ways。

lovegq

对于一些老的设计，前后挨着一定不会映射到同一个cache line，对于现在的一些设计，有可能，但是概率极低。退一步，就算映射到一个line也无所谓，毕竟还有那么多ways。

兄弟，有没有什么相关资料？发现自己这方面完全空白，多谢多谢

liuiang

这个入门应该够了。另外，感谢作者。

lovegq

十分感谢

luoyan_xy

回复 2# 瀚海书香


    我认为是这个原因：
            spin_lock的加锁是需要修改变量内容的，每次写会导致cache失效，可能会导致cache的错误共享，比如在多核上，一个核加锁导致另一个核cache失效

liuiang

我理解，目的是：将锁和锁要保护的数据放在同一cache line（或者相邻的），这样可以降低cache一致性交易。

试想一下，一个处理器对一个spinlock上了锁，就可以认为短时间内在cache line有了独占状态，那么随后的访问如果正好命中在这个cacheline上，显然效率最高。

如果spinlock的访问使得cacheline获得独占，而结果所访问的数据却cache miss了，那还得花时间将数据load到cache中，性能会有下降。