mirror of
https://github.com/gatieme/LDD-LinuxDeviceDrivers.git
synced 2026-08-17 16:52:08 +08:00
description: update patchwork series @20230630
This commit is contained in:
Cheng Jian
Vendored
+116
-70
@@ -15,19 +15,19 @@ blogexcerpt: 虚拟化 & KVM 子系统
|
||||
|
||||
<br>
|
||||
|
||||
本作品采用<a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/4.0/">知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议</a>进行许可, 转载请注明出处, 谢谢合作
|
||||
本作品采用 <a rel="license"href="http://creativecommons.org/licenses/by-nc-sa/4.0/"> 知识共享署名 - 非商业性使用 - 相同方式共享 4.0 国际许可协议 </a> 进行许可, 转载请注明出处, 谢谢合作
|
||||
|
||||
<a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/4.0/"><img alt="知识共享许可协议" style="border-width:0" src="https://i.creativecommons.org/l/by-nc-sa/4.0/88x31.png" /></a>
|
||||
<a rel="license"href="http://creativecommons.org/licenses/by-nc-sa/4.0/"><img alt=" 知识共享许可协议 "style="border-width:0"src="https://i.creativecommons.org/l/by-nc-sa/4.0/88x31.png"/></a>
|
||||
|
||||
因本人技术水平和知识面有限, 内容如有纰漏或者需要修正的地方, 欢迎大家指正, 鄙人在此谢谢啦
|
||||
|
||||
**转载请务必注明出处, 谢谢, 不胜感激**
|
||||
** 转载请务必注明出处, 谢谢, 不胜感激 **
|
||||
|
||||
<br>
|
||||
|
||||
| 日期 | 作者 | GitHub| CSDN | BLOG |
|
||||
| ------- |:-------:|:-------:|:-------:|:-------:|
|
||||
| 2021-02-15 | [成坚-gatieme](https://kernel.blog.csdn.net) | [`AderXCoding/system/tools/fzf`](https://github.com/gatieme/AderXCoding/tree/master/system/tools/fzf) | [使用模糊搜索神器 FZF 来提升办公体验](https://blog.csdn.net/gatieme/article/details/113828826) | [Using FZF to Improve Productivit](https://oskernellab.com/2021/02/15/2021/0215-0001-Using_FZF_to_Improve_Productivity)|
|
||||
| 2021-02-15 | [成坚 - gatieme](https://kernel.blog.csdn.net) | [`AderXCoding/system/tools/fzf`](https://github.com/gatieme/AderXCoding/tree/master/system/tools/fzf) | [使用模糊搜索神器 FZF 来提升办公体验](https://blog.csdn.net/gatieme/article/details/113828826) | [Using FZF to Improve Productivit](https://oskernellab.com/2021/02/15/2021/0215-0001-Using_FZF_to_Improve_Productivity)|
|
||||
|
||||
|
||||
<br>
|
||||
@@ -36,20 +36,20 @@ blogexcerpt: 虚拟化 & KVM 子系统
|
||||
-------
|
||||
|
||||
|
||||
# 2 缓存一致性协议--MESI协议
|
||||
# 2 缓存一致性协议 --MESI 协议
|
||||
-------
|
||||
|
||||
由于现在一般是多核处理器, 每个处理器都有自己的高速缓存, 那么会导致一些问题:
|
||||
|
||||
当某一个数据在多个处于 "运行" 状态的线程中进行读写共享时(例如 ThreadA、ThreadB 和 ThreadC)
|
||||
当某一个数据在多个处于 "运行" 状态的线程中进行读写共享时 (例如 ThreadA、ThreadB 和 ThreadC)
|
||||
|
||||
1. 第一个问题是多个线程可能在多个独立的 CPU 内核中"同时" 修改数据 A, 导致系统不知应该以哪个数据为准;
|
||||
1. 第一个问题是多个线程可能在多个独立的 CPU 内核中 "同时" 修改数据 A, 导致系统不知应该以哪个数据为准;
|
||||
|
||||
2. 第二个问题是由于ThreadA进行数据A的修改后没有即时写会内存, ThreadB和ThreadC也没有即时拿到新的数据A, 导致ThreadB和ThreadC对于修改后的数据不可见.
|
||||
2. 第二个问题是由于 ThreadA 进行数据 A 的修改后没有即时写会内存, ThreadB 和 ThreadC 也没有即时拿到新的数据 A, 导致 ThreadB 和 ThreadC 对于修改后的数据不可见.
|
||||
|
||||
这就是缓存一致性问题.
|
||||
|
||||
为了解决这个问题, 处理器之间需要一种通信机制----缓存一致性协议.
|
||||
为了解决这个问题, 处理器之间需要一种通信机制 ---- 缓存一致性协议.
|
||||
|
||||
|
||||
## 2.1 MESI 状态
|
||||
@@ -57,20 +57,20 @@ blogexcerpt: 虚拟化 & KVM 子系统
|
||||
|
||||
MESI(Modified-Exclusive-Shared-Invalid) 协议是一种广为使用的缓存一致性协议. MESI 协议对内存数据访问的控制类似于读写锁, 它使得针对同一地址的读内存操作是并发的, 而针对同一地址的写内存操作是独占的.
|
||||
|
||||
之所以叫 MESI, 是因为这套方案把一个缓存行(cache line)区分出四种不同的状态标记, 他们分别是 Modified、Exclusive、Shared 和 Invalid. 这四种状态分别具备一定的意义:
|
||||
之所以叫 MESI, 是因为这套方案把一个缓存行 (cache line) 区分出四种不同的状态标记, 他们分别是 Modified、Exclusive、Shared 和 Invalid. 这四种状态分别具备一定的意义:
|
||||
|
||||
| 状态 | 描述 | 监听任务 | 状态转换 |
|
||||
|:---:|:----:|:------:|:-------:|
|
||||
| M 修改 (Modified) | 该 Cache line 有效, 但是数据被修改了(和内存中的数据不一致), 并且该数据只存在于本 Cache 中.<br>在未来的某个时刻该数据会被写入到内存中(一般在其他 CPU 要读取该缓存行的内容时. 或者其他 CPU 要修改该缓存对应的内存中的内容时 | 缓存行必须时刻监听所有试图读该缓存行相对就主存的操作, 这种操作必须在缓存将该缓存行写回主存并将状态变成S(共享)状态之前被延迟执行. | 当被写回主存之后, 该缓存行的状态会变成独享(exclusive)状态. |
|
||||
| E 独享、互斥 (Exclusive) | 该 Cache line 有效, 数据和内存中的数据一致, 并且数据只存在于本Cache中. | 缓存行也必须监听其它缓存读主存中该缓存行的操作, 一旦有这种操作, 该缓存行需要变成S(共享)状态.| 该缓存可以在任何其他 CPU 读取该缓存对应内存中的内容时变成 S 状态. 或者本地处理器写该缓存就会变成 M 状态. |
|
||||
| S 共享 (Shared) | 该 Cache line 有效, 数据和内存中的数据一致, 数据存在于很多 Cache 中. | 当前缓存行必须监听其它缓存使该缓存行无效或者独享该缓存行的请求, 并将该缓存行变成无效(Invalid). | 当其他 CPU 修改该缓存行对应的内存时会使该缓存行变成 I 状态. |
|
||||
| M 修改 (Modified) | 该 Cache line 有效, 但是数据被修改了 (和内存中的数据不一致), 并且该数据只存在于本 Cache 中.<br> 在未来的某个时刻该数据会被写入到内存中 (一般在其他 CPU 要读取该缓存行的内容时. 或者其他 CPU 要修改该缓存对应的内存中的内容时 | 缓存行必须时刻监听所有试图读该缓存行相对就主存的操作, 这种操作必须在缓存将该缓存行写回主存并将状态变成 S(共享) 状态之前被延迟执行. | 当被写回主存之后, 该缓存行的状态会变成独享 (exclusive) 状态. |
|
||||
| E 独享、互斥 (Exclusive) | 该 Cache line 有效, 数据和内存中的数据一致, 并且数据只存在于本 Cache 中. | 缓存行也必须监听其它缓存读主存中该缓存行的操作, 一旦有这种操作, 该缓存行需要变成 S(共享) 状态.| 该缓存可以在任何其他 CPU 读取该缓存对应内存中的内容时变成 S 状态. 或者本地处理器写该缓存就会变成 M 状态. |
|
||||
| S 共享 (Shared) | 该 Cache line 有效, 数据和内存中的数据一致, 数据存在于很多 Cache 中. | 当前缓存行必须监听其它缓存使该缓存行无效或者独享该缓存行的请求, 并将该缓存行变成无效 (Invalid). | 当其他 CPU 修改该缓存行对应的内存时会使该缓存行变成 I 状态. |
|
||||
| I 无效 (Invalid) | 该 Cache line 无效. | 无 | 无 |
|
||||
|
||||
监听:
|
||||
|
||||
1. 一个处于 M 状态的缓存行必须时刻监听所有试图读该缓存行相对就主存的操作, 这种操作必须在缓存将该缓存行写回主存并将状态变成 S 状态之前被延迟执行.
|
||||
|
||||
2. 一个处于 S 状态的缓存行也必须监听其它缓存使该缓存行无效或者独享该缓存行的请求, 并将该缓存行变成无效(Invalid).
|
||||
2. 一个处于 S 状态的缓存行也必须监听其它缓存使该缓存行无效或者独享该缓存行的请求, 并将该缓存行变成无效 (Invalid).
|
||||
|
||||
3. 一个处于 E 状态的缓存行也必须监听其它缓存读主存中该缓存行的操作, 一旦有这种操作, 该缓存行需要变成 S 状态.
|
||||
|
||||
@@ -85,7 +85,7 @@ MESI(Modified-Exclusive-Shared-Invalid) 协议是一种广为使用的缓存一
|
||||
|:---:|:----:|:---:|
|
||||
| Read | 请求 | 用来获取指定物理地址上的 cache line 数据. 通知其他处理器和内存, 当前 CPU 准备读取某个数据. 该消息内包含待读取数据的内存地址. |
|
||||
| Read Response | 响应 | Read 请求的响应信息, 该消息内包含了被请求读取的数据. 该消息可能是主内存返回的, 也可能是其他高速缓存嗅探到 Read 消息返回的. |
|
||||
| Invalidate | 请求 | 通知其他处理器删除(无效)指定内存地址的数据副本(缓存行中的数据). 该消息包含数据的内存物理地址. |
|
||||
| Invalidate | 请求 | 通知其他处理器删除 (无效) 指定内存地址的数据副本 (缓存行中的数据). 该消息包含数据的内存物理地址. |
|
||||
| Invalidate Acknowledge | 响应 | 这是 CPU 对 Invalidate 消息的响应, 接收到 Invalidate 消息的处理器必须回复此消息, 表示已经无效掉了其高速缓存内对应的数据副本. |
|
||||
| Read Invalidate | 请求 | 这个消息其实是 Read 和 Invalidate 消息组成的复合消息, 主要是用于通知其他 CPU 当前 CPU 准备更新一个数据了, 所以获取对该数据的独占权, 并请求其他处理器删除其高速缓存内对应的数据副本. 接收到该消息的处理器必须回复 Read Response 和 Invalidate Acknowledge 消息. |
|
||||
| Writeback | 响应 | 消息包含了需要写入内存的数据和其对应的内存地址, 一般用在 modified 状态的 cache line 被置换时发出, 用来将最新的数据写回 memory 或其他下一级 cache 中. |
|
||||
@@ -98,20 +98,20 @@ MESI(Modified-Exclusive-Shared-Invalid) 协议是一种广为使用的缓存一
|
||||
|
||||
MESI 状态转换的规则如下:
|
||||
|
||||
1. 一个缓存除在 Invalid 状态外都可以满足 CPU 的读请求, 一个 Invalid 的缓存行必须从主存中读取(变成 S 或者 E 状态)来满足该 CPU 的读请求.
|
||||
1. 一个缓存除在 Invalid 状态外都可以满足 CPU 的读请求, 一个 Invalid 的缓存行必须从主存中读取 (变成 S 或者 E 状态) 来满足该 CPU 的读请求.
|
||||
|
||||
2. 一个写请求只有在该缓存行是 M 或者 E 状态时才能被执行, 如果缓存行处于 S 状态, 必须先将其它缓存中该缓存行变成 Invalid 状态(也既是不允许不同 CPU 同时修改同一缓存行, 即使修改该缓存行中不同位置的数据也不允许). 该操作经常作用广播的方式来完成, 例如: RequestFor Ownership (RFO).
|
||||
2. 一个写请求只有在该缓存行是 M 或者 E 状态时才能被执行, 如果缓存行处于 S 状态, 必须先将其它缓存中该缓存行变成 Invalid 状态 (也既是不允许不同 CPU 同时修改同一缓存行, 即使修改该缓存行中不同位置的数据也不允许). 该操作经常作用广播的方式来完成, 例如: RequestFor Ownership (RFO).
|
||||
|
||||
3. 缓存可以随时将一个非 M 状态的缓存行作废, 或者变成 Invalid 状态, 而一个 M 状态的缓存行必须先被写回主存.
|
||||
|
||||
4. 从上面的意义看来 E 状态是一种投机性的优化: 如果一个 CPU 想修改一个处于 S 状态的缓存行, 总线事务需要将所有该缓存行的 copy 变成 Invalid 状态, 而修改 E 状态的缓存不需要使用总线事务.
|
||||
|
||||
5. 对于 M 和 E 状态而言总是精确的, 他们和该缓存行的实际状态是一致的. 而 S 状态可能是非一致的, 如果一个缓存将处于 S 状态的缓存行作废了, 而另一个缓存实际上可能已经独享了该缓存行, 但是该缓存却不会将该缓存行升迁为 E 状态, 这是因为其它缓存不会广播他们作废掉该缓存行的通知, 同样由于缓存并没有保存该缓存行的 copy 的数量, 因此(即使有这种通知)也没有办法确定自己是否已经独享了该缓存行. 因此上述状态转换的表格中, 中间状态可能并不会发生.
|
||||
5. 对于 M 和 E 状态而言总是精确的, 他们和该缓存行的实际状态是一致的. 而 S 状态可能是非一致的, 如果一个缓存将处于 S 状态的缓存行作废了, 而另一个缓存实际上可能已经独享了该缓存行, 但是该缓存却不会将该缓存行升迁为 E 状态, 这是因为其它缓存不会广播他们作废掉该缓存行的通知, 同样由于缓存并没有保存该缓存行的 copy 的数量, 因此 (即使有这种通知) 也没有办法确定自己是否已经独享了该缓存行. 因此上述状态转换的表格中, 中间状态可能并不会发生.
|
||||
|
||||
|
||||
|
||||
local read 和 local write 分别代表本地CPU读写.
|
||||
remote read 和 remote write 分别代表其他CPU读写.
|
||||
local read 和 local write 分别代表本地 CPU 读写.
|
||||
remote read 和 remote write 分别代表其他 CPU 读写.
|
||||
|
||||
|
||||
|
||||
@@ -119,29 +119,29 @@ remote read 和 remote write 分别代表其他CPU读写.
|
||||
|:------:|:----:|:---:|:--------------------:|:----------------------------:|:-------------:|
|
||||
| M(modified) | local read | 状态不变 | M | M | I |
|
||||
| M(modified) | local write | 状态不变 | M | M | I |
|
||||
| M(modified) | remote read | 在本 CPU 独自享受独占数据的时候, 其他的 CPU 发起 read 请求, 希望获取数据, 这时候, 本 CPU 必须以其 local cacheline 的数据回应, 并以 read response 回应之前总线上的 read 请求. 这时候, 本 CPU 失去了独占权, 该 cacheline 状态从 Modified 状态变成 Shared 状态(有可能也会进行写回的动作, 写会后, 可能存在中间状态 E). | M->E->S | I->S | I->S |
|
||||
| M(modified) | remote write | ~~先把 cache 中的数据写到内存中, 其他 CPU 的 cache 再读取并修改后, 本地 cache 状态变为I. 修改的那个cache状态变为 M~~<br>CPU 收到一个 read invalidate 消息, 此时 CPU 必须将对应 cache line 设置成 invalid 状态, 并且响应一个 read response 消息和 invalidate acknowledge 消息. | I | M->E->S->I | I->S->E->M | I->S->I |
|
||||
| M(modified) | remote read | 在本 CPU 独自享受独占数据的时候, 其他的 CPU 发起 read 请求, 希望获取数据, 这时候, 本 CPU 必须以其 local cacheline 的数据回应, 并以 read response 回应之前总线上的 read 请求. 这时候, 本 CPU 失去了独占权, 该 cacheline 状态从 Modified 状态变成 Shared 状态 (有可能也会进行写回的动作, 写会后, 可能存在中间状态 E). | M->E->S | I->S | I->S |
|
||||
| M(modified) | remote write | ~~ 先把 cache 中的数据写到内存中, 其他 CPU 的 cache 再读取并修改后, 本地 cache 状态变为 I. 修改的那个 cache 状态变为 M~~<br>CPU 收到一个 read invalidate 消息, 此时 CPU 必须将对应 cache line 设置成 invalid 状态, 并且响应一个 read response 消息和 invalidate acknowledge 消息. | I | M->E->S->I | I->S->E->M | I->S->I |
|
||||
| M(modified) | write back | cache 通过 writeback 将数据回写到 memory 或者下一级 cache 中. 这时候状态由 modified 变成了 exclusive | E | E | I |
|
||||
| <br>*-* <br> | <br>*-* <br> | <br>*-* <br> |<br>*-*-*-* <br> |
|
||||
| E(exclusive) | local read | 状态不变 | E | E | I |
|
||||
| E(exclusive) | local write | CPU 直接将数据写入 cache line, 导致状态变为了 M | E->M | E->M | I |
|
||||
| E(exclusive) | remote read | 这个迁移和(M-=>S)的转换类似, 只不过开始 cacheline 的状态是 exclusive, cacheline 和 memory 的数据都是最新的, 不存在写回的问题. 总线上的操作也是在收到 read 请求之后, 以read response 回应. 本 CPU 失去了独占权, 该 cacheline 状态从 Modified 状态变成 shared 状态(不会进行写回的动作) | E->S | E->S | I->S |
|
||||
| E(exclusive) | remote write | 其他的 CPU 进行一个原子的 read-modify-write 操作, 但是, 数据在本 CPU 的 cacheline 中, 因此, 其他的那个 CPU 会发送 read invalidate, 请求该数据(可能存在存在中间状态 S)以及获取独占权(可能存在存在中间状态 E). 本 CPU 回送 read response 和 invalidate acknowledge, 一方面把数据转移到其他 CPU 的 cache 中(存在中间状态 S), 另外一方面, 清空自己的 cacheline. | E->S->I | I->S->E->M | I->S->I |
|
||||
| E(exclusive) | remote read | 这个迁移和 (M-=>S) 的转换类似, 只不过开始 cacheline 的状态是 exclusive, cacheline 和 memory 的数据都是最新的, 不存在写回的问题. 总线上的操作也是在收到 read 请求之后, 以 read response 回应. 本 CPU 失去了独占权, 该 cacheline 状态从 Modified 状态变成 shared 状态 (不会进行写回的动作) | E->S | E->S | I->S |
|
||||
| E(exclusive) | remote write | 其他的 CPU 进行一个原子的 read-modify-write 操作, 但是, 数据在本 CPU 的 cacheline 中, 因此, 其他的那个 CPU 会发送 read invalidate, 请求该数据 (可能存在存在中间状态 S) 以及获取独占权 (可能存在存在中间状态 E). 本 CPU 回送 read response 和 invalidate acknowledge, 一方面把数据转移到其他 CPU 的 cache 中 (存在中间状态 S), 另外一方面, 清空自己的 cacheline. | E->S->I | I->S->E->M | I->S->I |
|
||||
| <br>*-* <br> | <br>*-* <br> | <br>*-* <br> |<br>*-*-*-* <br> |
|
||||
| S(shared) | local read | 不影响状态 | S | S | S |
|
||||
| S(shared) | local write | CPU 需要执行一个原子的 readmodify-write 操作, 并且其 local cache 中有 read only 的缓存数据(cache line 处于 Shared 状态), 这时候, CPU 就会在总线上发送一个 invalidate 请求其他 CPU 清空自己的 local copy, 以便完成其独自霸占对该数据的所有权的梦想(存在中间状态 E). 同样的, 该 CPU 必须收集所有其他 CPU 发来的 invalidate acknowledge 之后才能更改状态为 modified. | S->E->M | S->E->M | S->I |
|
||||
| S(shared) | local write | CPU 需要执行一个原子的 readmodify-write 操作, 并且其 local cache 中有 read only 的缓存数据 (cache line 处于 Shared 状态), 这时候, CPU 就会在总线上发送一个 invalidate 请求其他 CPU 清空自己的 local copy, 以便完成其独自霸占对该数据的所有权的梦想 (存在中间状态 E). 同样的, 该 CPU 必须收集所有其他 CPU 发来的 invalidate acknowledge 之后才能更改状态为 modified. | S->E->M | S->E->M | S->I |
|
||||
| S(shared) | remote read | 不影响状态 | S | S | S |
|
||||
| S(shared) | remote write | 当 cache line 处于 shared 状态的时候, 说明在多个 CPU 的 local cache 中存在副本, 因此, 这些 cache line 中的数据都是 read only 的, 一旦其中一个 CPU 想要执行数据写入的动作, 必须先通过 invalidate 获取该数据的独占权(可能存在中间状态 E), 而其他的 CPU 会以 invalidate acknowledge 回应, 清空数据并将其 cacheline 从 shared 状态修改成 invalid 状态. 在写完成后, 本次 cache line 变成 modified 状态 | S->I | S->E->M | S->I |
|
||||
| S(shared) | NA | 如果 CPU 认为自己很快就会启动对处于 shared 状态的 cacheline 进行 write 操作, 因此想提前先霸占上该数据. 因此, 该 CPU 会发送 invalidate 敦促其他 CPU 清空自己的 local copy, 当收到全部其他 CPU 的 invalidate acknowledge 之后, transaction 完成, 本 CPU 上对应的 cacheline 从 shared 状态切换 exclusive 状态.<br>还有另外一种方法也可以完成这个状态切换: 当所有其他的 CPU 对其 local copy 的 cacheline 进行写回操作, 同时将 cacheline 中的数据设为无效(主要是为了为新的数据腾些地方), 这时候, 本 CPU 坐享其成, 直接获得了对该数据的独占权. | E | E/I | I |
|
||||
| S(shared) | remote write | 当 cache line 处于 shared 状态的时候, 说明在多个 CPU 的 local cache 中存在副本, 因此, 这些 cache line 中的数据都是 read only 的, 一旦其中一个 CPU 想要执行数据写入的动作, 必须先通过 invalidate 获取该数据的独占权 (可能存在中间状态 E), 而其他的 CPU 会以 invalidate acknowledge 回应, 清空数据并将其 cacheline 从 shared 状态修改成 invalid 状态. 在写完成后, 本次 cache line 变成 modified 状态 | S->I | S->E->M | S->I |
|
||||
| S(shared) | NA | 如果 CPU 认为自己很快就会启动对处于 shared 状态的 cacheline 进行 write 操作, 因此想提前先霸占上该数据. 因此, 该 CPU 会发送 invalidate 敦促其他 CPU 清空自己的 local copy, 当收到全部其他 CPU 的 invalidate acknowledge 之后, transaction 完成, 本 CPU 上对应的 cacheline 从 shared 状态切换 exclusive 状态.<br> 还有另外一种方法也可以完成这个状态切换: 当所有其他的 CPU 对其 local copy 的 cacheline 进行写回操作, 同时将 cacheline 中的数据设为无效 (主要是为了为新的数据腾些地方), 这时候, 本 CPU 坐享其成, 直接获得了对该数据的独占权. | E | E/I | I |
|
||||
| <br>*-* <br> | <br>*-* <br> | <br>*-* <br> |<br>*-*-*-* <br> |
|
||||
| I(invalid) | local read | 本 CPU 执行读操作, 发现 local cache 没有数据, 因此通过 read 发起一次 bus transaction, 来自其他的 CPU local cache 或者 memory 会通过 read response 回应,<br>1. 如果数据来自其他 CPU 的 cache, 将该 cache line 从 Invalid 状态迁移到 Shared 状态.<br>2. 如果来自于内存, 则本地从 Invalid 状态迁移到 Exclusive 状态. | I->S/I->E | I->S/I->E | E/M/I->S/I |
|
||||
| I(invalid) | local write | CPU 想要进行 write 的操作但是数据不在 local cache 中, 因此, 该 CPU 首先发送了 read invalidate 启动了一次总线 transaction. 在收到 read response 回应拿到数据, 并且收集所有其他 CPU 发来的 invalidate acknowledge 之后(确保其他 CPU 没有 local copy), 完成整个 bus transaction. 当 write 操作完成之后, 该 cacheline的状态会从 I 状态迁移到 E 状态. | E | E | E |
|
||||
| I(invalid) | local write | CPU 需要执行一个原子的 readmodify-write 操作, 并且其 cache 中没有缓存数据. 这时候 CPU 就会在总线上发送一个 read invalidate 消息来请求数据(可能存在中间状态 S), 并试图独占该数据(可能存在中间状态 E). CPU 可以通过收到的 read response 消息获取到数据, 并等待所有的 invalidate acknowledge 消息, 然后将状态设置为 modifie. | I->S->E->M | I->S->E->M | M,E,S->S->I |
|
||||
| I(invalid) | local write | CPU 想要进行 write 的操作但是数据不在 local cache 中, 因此, 该 CPU 首先发送了 read invalidate 启动了一次总线 transaction. 在收到 read response 回应拿到数据, 并且收集所有其他 CPU 发来的 invalidate acknowledge 之后 (确保其他 CPU 没有 local copy), 完成整个 bus transaction. 当 write 操作完成之后, 该 cacheline 的状态会从 I 状态迁移到 E 状态. | E | E | E |
|
||||
| I(invalid) | local write | CPU 需要执行一个原子的 readmodify-write 操作, 并且其 cache 中没有缓存数据. 这时候 CPU 就会在总线上发送一个 read invalidate 消息来请求数据 (可能存在中间状态 S), 并试图独占该数据 (可能存在中间状态 E). CPU 可以通过收到的 read response 消息获取到数据, 并等待所有的 invalidate acknowledge 消息, 然后将状态设置为 modifie. | I->S->E->M | I->S->E->M | M,E,S->S->I |
|
||||
| I(invalid) | remote read | remote read 不影响本地 cache 的状态 | I | NA | NA |
|
||||
| I(invalid) | remote write | remote read 不影响本地 cache 的状态 | I | NA | NA |
|
||||
|
||||
|
||||
下图示意了，当本地 cache line 的调整的状态的时候, 其他 CPU 的 cache line 需要调整到的状态.
|
||||
下图示意了, 当本地 cache line 的调整的状态的时候, 其他 CPU 的 cache line 需要调整到的状态.
|
||||
|
||||
| M | E | S | I |
|
||||
|:-:|:-:|:-:|:-:|
|
||||
@@ -152,90 +152,136 @@ remote read 和 remote write 分别代表其他CPU读写.
|
||||
|
||||
举个栗子来说:
|
||||
|
||||
假设 CPU 1 的 cache line 中有一个变量 x = 0 的 cache line 处于 S 状态(共享).
|
||||
那么其他拥有 x 变量的 CPU 2, CPU 3 等的 cache line 可能调整到的状态就是 S 状态(共享)或者调整为 I 状态(无效).
|
||||
假设 CPU 1 的 cache line 中有一个变量 x = 0 的 cache line 处于 S 状态 (共享).
|
||||
那么其他拥有 x 变量的 CPU 2, CPU 3 等的 cache line 可能调整到的状态就是 S 状态 (共享) 或者调整为 I 状态 (无效).
|
||||
|
||||
|
||||
# 3 硬件的处理
|
||||
-------
|
||||
|
||||
## 3.1 Store Buffer
|
||||
## 3.1 L3 Cache 在 MESI 中的角色
|
||||
-------
|
||||
|
||||
当然前面的描述隐藏了一些细节, 比如实际 CPU1 在执行写操作, 更新缓存行的时候, 其实并不会等待其他 CPU 的状态都置为 I 状态, 才去做些操作, 这是一个同步行为, 效率很低. 当前的 CPU 都引入了 Store Buffer(写缓存器)技术, 也就是在 CPU 和 cache 之间又加了一层 buffer, 在 CPU 执行写操作时直接写 StoreBuffer, 然后就忙其他事去了, 等接收到其他 CPU 返回的 Invalidate Acknowledge 响应 后, CPU1 才把 buffer 中的数据写入到缓存行中.
|
||||
L3 缓存是所有 CPU 共享的一个缓存. 纵观刚才描述的 MESI, 好像涉及的都是 CPU 内的缓存更新, 不涉及 L3 缓存, 那么 L3 缓存在 MESI 中扮演什么角色呢 ?
|
||||
|
||||
引入了 Store Buffer 之后, 后续 CPU1 读取数据的时候, 会先查 Store Buffer, 再查 cache line.
|
||||
其实在常见的 MESI 的状态流程描述中, 所有提到 "内存" 的地方都是值得商榷的. 比如我上一节举的例子中, CPU0 中某缓存行是 I, CPU1 中是 M. 当 CPU0 想到执行 local read 操作时, 就会触发 CPU1 中的缓存写入到内存中, 然后 CPU0 从内存中取最新的缓存行. 其实准确来讲这里是不准确的, 因为由于 L3 缓存的存在, 这里其实是直接从 L3 缓存读取缓存行, 而不直接访问内存.
|
||||
|
||||
个人猜测是如果描述 MESI 状态流转的时候引入 L3 缓存, 会造成描述会极其复杂. 所以一般的描述都好似有意地忽略了 L3 缓存.
|
||||
|
||||
|
||||
## 3.2 Invalidate Queue
|
||||
## 3.2 Store Buffer
|
||||
-------
|
||||
|
||||
看前面的描述, 执行写操作的CPU1很聪明啦, 引入了 store buffer 不等待其他CPU中的对应缓存行失效就忙别的去了. 而其他 CPU 也不傻, 实际上他们也不会真的把缓存行置为 I 后, 才给 CPU0 发响应. 他们会写入一个 Invalidate Queue(无效化队列), 还没把缓存置为 I 状态就发送响应了.
|
||||
### 3.2.1 Store Buffer 的作用
|
||||
-------
|
||||
|
||||
当然前面的描述隐藏了一些细节, 比如实际 CPU1 在执行写操作, 更新缓存行的时候, 其实并不会等待其他 CPU 的状态都置为 I 状态, 才去做些操作, 这是一个同步行为, 效率很低. 当前的 CPU 都引入了 Store Buffer(写缓存器) 技术, 也就是在 CPU 和 cache 之间又加了一层 buffer, 在 CPU 执行写操作时直接写 StoreBuffer, 然后就忙其他事去了, 等接收到其他 CPU 返回的 Invalidate Acknowledge 响应 后, CPU1 才把 buffer 中的数据写入到缓存行中.
|
||||
|
||||
### 3.2.2 Store Buffer 引入的问题
|
||||
-------
|
||||
|
||||
Store Buffer 会引入的数据可见性问题, 因为数据已经修改了, 但是没有更新到 Cache, 不被 Cache 一致性感知. 大家读取这个变量和数据的时候, 并不能知道某个核的 Store Buffer 中可能存有一个这个值的最新值, 因此读取到的依旧是旧值. 这就引入了数据可见性的问题.
|
||||
|
||||
|
||||
| 观察者 | 问题 | 解决方案 |
|
||||
|:-----:|:---:|:-------:|
|
||||
| 本核 | 本核对一个变量 X 更新后, 再读取它的值, 由于可能变量 X 的最新值在 Store Buffer 中, 本核可能读出来一个旧值, 这是完全不允许的. 因此它直接破坏了程序预期的逻辑. | 引入了 Store Buffer 之后, 后续当前 CPU 读取数据的时候, 必须先查 Store Buffer, 再查 cache line. 这种 Store Buffer 设计上的策略叫做 Store Forwarding. 这种策略是必须实现的, 否则单核上自己从 Cache 上看到的数据都是旧的 (错的). 就是说核 A 在读取数据的时候会先看 Store Buffer 中的数据, 如果 Store Buffer 中有数据, 直接使用 Store Buffer 中的, 从而避免使用错误数据. |
|
||||
| 其他核 | 在多核情况下, 核 B 在进行判断的时候发现在自己的缓存存在 x=0, 但此时核 A 刚刚将 x = 2 的操作放到 Store Buffer 中, 所以由于 Store Buffer 的存在导致多核下不能获取到最新值, 所以产生了错误的结果. | 为了解决这个问题出现了写屏障, 写屏障的出现保证屏障两边写的执行是分开的, 也就是说需要先将之前 Store Buffer 中的所有写指令都刷新到缓存之后, 才执行后面的写指令. 具体实现方法是, 先将屏障之前的 Store Buffer 中所有操作都刷新到缓存中, 将屏障后的所有指令操作也同样放到 Store Buffer 中, 不管后续的操作是什么都往里面放, 这样可以提高 CPU 的执行效率, 都通过 Store Buffer 刷新到了缓存中. |
|
||||
|
||||
## 3.3 Invalidate Queue
|
||||
-------
|
||||
|
||||
### 3.3.1 Invalidate Queue 的作用
|
||||
-------
|
||||
|
||||
看前面的描述, 执行写操作的 CPU1 很聪明啦, 引入了 store buffer 不等待其他 CPU 中的对应缓存行失效就忙别的去了. 而其他 CPU 也不傻, 实际上他们也不会真的把缓存行置为 I 后, 才给 CPU0 发响应. 他们会写入一个 Invalidate Queue(无效化队列), 还没把缓存置为 I 状态就发送响应了.
|
||||
|
||||
后续 CPU 会异步扫描 Invalidate Queue, 将缓存置为 I 状态.
|
||||
|
||||
和 Store Buffer 不同的是, 在 CPU1 后续读取数据的时候, 会先查 Store Buffer, 再查缓存. 而 CPU0 要读取数据时, 则不会扫描 Invalidate Queue, 所以存在脏读可能.
|
||||
|
||||
## 3.3 L3 Cache在 MESI 中的角色
|
||||
### 3.3.2 Invalidate Queue 引入的问题
|
||||
-------
|
||||
|
||||
L3 缓存是所有CPU共享的一个缓存. 纵观刚才描述的MESI, 好像涉及的都是CPU内的缓存更新, 不涉及L3缓存, 那么L3缓存在MESI中扮演什么角色呢 ?
|
||||
和 Store Buffer 不同的是, 在 CPU1 后续读取数据的时候, 会先查 Store Buffer, 再查缓存. 而 CPU0 要读取数据时, 则不会扫描 Invalidate Queue, 所以存在脏读可能.
|
||||
|
||||
其实在常见的 MESI 的状态流程描述中, 所有提到"内存"的地方都是值得商榷的. 比如我上一节举的例子中, CPU0中某缓存行是I, CPU1 中是M. 当CPU0想到执行local read操作时, 就会触发CPU1中的缓存写入到内存中, 然后CPU0从内存中取最新的缓存行. 其实准确来讲这里是不准确的, 因为由于L3缓存的存在, 这里其实是直接从L3缓存读取缓存行, 而不直接访问内存.
|
||||
|
||||
个人猜测是如果描述MESI状态流转的时候引入L3缓存, 会造成描述会极其复杂. 所以一般的描述都好似有意地忽略了L3缓存.
|
||||
核 B 在进行判断的时候发现在自己的缓存存在 x, 但此时核 B 刚刚将接收到的其他核对 x 更新的操作放到 Invalidate Queue 中, 所以由于 Invalidate Queue 的存在导致多核下不能获取到最新值, 所以产生了错误的结果.
|
||||
|
||||
所以为了解决上面的问题出现了读屏障, 读屏障的出现保证屏障两边读的执行是分开的, 也就是说需要先将之前 Invalidate Queue 中的所有指令都失效之后, 才执行后面的指令, 保证下一次读取共享变量的时候读到的是最新的变量.
|
||||
|
||||
通过以上两个操作的结合使用可以保证在多核的情况下对共享变量的修改和读取都是一致的.
|
||||
|
||||
|
||||
## 3.4 内存屏障 (Memory Barrier)
|
||||
-------
|
||||
|
||||
通过上面对错误情况的分析可以知道, 内存屏障的出现就是为了解决因为 Store Buffer 和 Invalidate Queue 所带来的数据可见性问题, 也就是读和写不能实时更新到其他核的问题. 内存屏障同时还具备强制将 Store Buffer 的内容刷到缓存中, 强制将 Invalidate Queue 中的内容设置完毕的作用.
|
||||
|
||||
具体又分为写屏障和读屏障
|
||||
|
||||
| 屏障类型 | 描述 |
|
||||
|:-------:|:---:|
|
||||
| 写屏障 (Store Memory Barrier) | 强制将 Store Buffer 中的内容写入到缓存中或者将该指令之后的写操作写入 Store Buffer 直到之前的内容被刷入到缓存中, 也被称之为 smp_wmb |
|
||||
| 读屏障 (Load Memory Barrier) | 强制将 Invalidate Queue 中的内容处理完毕, 也被称之为 smp_rmb |
|
||||
| 读写屏障 | 兼备以上两个屏障的功能, 也被称之为 smp_mb |
|
||||
|
||||
## 3.5 有序性
|
||||
-------
|
||||
|
||||
同时保证了在写屏障之前所有的写操作都已经完成, 在读屏障之前所有的无效都已经设置完成, 也就是说保证了程序执行的有序性, 为什么这么说呢, 因为本来在 CPU 执行指令的时候为了提高效率会将写的操作放入到 Store Buffer 中去, 然后去执行其他操作, 这时给我们的感觉就是 CPU 在执行其他操作, 当 Store Buffer 中的操作异步收到其他核返回的信息后, 才执行 Store Buffer 中的操作, 这时执行顺序和本应该执行的顺序是相反的, 这种现象就是指令乱序执行. 而加上内存屏障之后保证异步中的操作执行完毕后才进行其他指令的执行, 在现象上保证了指令执行的有序性.
|
||||
|
||||
|
||||
# 4 参考资料
|
||||
-------
|
||||
|
||||
| 编号 | 链接 | 描述 |
|
||||
|:---:|:----:|:---:|
|
||||
| 1 | [理解Memory Barrier(内存屏障)](https://blog.csdn.net/caoshangpa/article/details/78853919) | NA |
|
||||
| 2 | [内存屏障(Memory Barrier)与volatile](https://blog.csdn.net/fedorafrog/article/details/113782404) | NA |
|
||||
| 3 | [OR1200处理器的Store Buffer分析](https://blog.csdn.net/leishangwen/article/details/35212811) | NA |
|
||||
| 1 | [理解 Memory Barrier(内存屏障)](https://blog.csdn.net/caoshangpa/article/details/78853919) | NA |
|
||||
| 2 | [内存屏障 (Memory Barrier) 与 volatile](https://blog.csdn.net/fedorafrog/article/details/113782404) | NA |
|
||||
| 3 | [OR1200 处理器的 Store Buffer 分析](https://blog.csdn.net/leishangwen/article/details/35212811) | NA |
|
||||
| 4 | [MESI 与 StoreBuffer 相互独立的猜想](https://www.cnblogs.com/lqlqlq/p/14414091.html) | NA |
|
||||
| 5 | [内存屏障的来历](https://zhuanlan.zhihu.com/p/125549632) | NA |
|
||||
| 6 | [内存屏障(Memory Barrier)究竟是个什么鬼？](https://www.bilibili.com/read/cv5131208) | NA |
|
||||
| 7 | [处理器中的存储问题(三):从Store Buffer到TSO存储模型](https://zhuanlan.zhihu.com/p/149302247) | NA |
|
||||
| 6 | [内存屏障 (Memory Barrier) 究竟是个什么鬼？](https://www.bilibili.com/read/cv5131208) | NA |
|
||||
| 7 | [处理器中的存储问题 (三): 从 Store Buffer 到 TSO 存储模型](https://zhuanlan.zhihu.com/p/149302247) | NA |
|
||||
| 8 | [CPU 缓存和 volatile](https://www.cnblogs.com/xmzJava/p/11417943.html) | MESI 有个图表 | NA |
|
||||
| 9 | [CPU多级缓存与缓存一致性, 详细的讲解](https://blog.csdn.net/weixin_43649997/article/details/108742221) | NA |
|
||||
| 10 | [CPU有缓存一致性协议(MESI), 为何还需要volatile](https://blog.csdn.net/org_hjh/article/details/109626607) | NA |
|
||||
| 11 | [笔记:CPU中的cache(二)](https://zhuanlan.zhihu.com/p/144836286) | NA |
|
||||
| 9 | [CPU 多级缓存与缓存一致性, 详细的讲解](https://blog.csdn.net/weixin_43649997/article/details/108742221) | NA |
|
||||
| 10 | [CPU 有缓存一致性协议 (MESI), 为何还需要 volatile](https://blog.csdn.net/org_hjh/article/details/109626607) | NA |
|
||||
| 11 | [笔记: CPU 中的 cache(二)](https://zhuanlan.zhihu.com/p/144836286) | NA |
|
||||
| 12 | [Reducing Design Complexity of the Load/Store Queue](https://engineering.purdue.edu/~vijay/papers/2003/lsq.pdf) | NA |
|
||||
| 13 | [乱序处理器中的LSQ简介](https://blog.csdn.net/baidu_35679960/article/details/79554428) | NA |
|
||||
| 14 | [简述 典型处理器(如Cortex A9)中一条存储器读写指令的执行全过程](https://blog.csdn.net/baidu_35679960/article/details/78571097) | MA |
|
||||
| 15 | [4.2 存储器读写指令的发射与执行1](https://blog.csdn.net/sailing_w/article/details/55003968) | NA |
|
||||
| 16 | [乱序处理器中的LSQ简介](https://blog.csdn.net/baidu_35679960/article/details/79554428) | NA |
|
||||
| 17 | [Volatile:内存屏障原理应该没有比这篇文章讲的更清楚了](https://www.bilibili.com/read/cv7429219/) | NA |
|
||||
| 13 | [乱序处理器中的 LSQ 简介](https://blog.csdn.net/baidu_35679960/article/details/79554428) | NA |
|
||||
| 14 | [简述 典型处理器 (如 Cortex A9) 中一条存储器读写指令的执行全过程](https://blog.csdn.net/baidu_35679960/article/details/78571097) | MA |
|
||||
| 15 | [4.2 存储器读写指令的发射与执行 1](https://blog.csdn.net/sailing_w/article/details/55003968) | NA |
|
||||
| 16 | [乱序处理器中的 LSQ 简介](https://blog.csdn.net/baidu_35679960/article/details/79554428) | NA |
|
||||
| 17 | [Volatile: 内存屏障原理应该没有比这篇文章讲的更清楚了](https://www.bilibili.com/read/cv7429219/) | NA |
|
||||
| 18 | [内存一致性模型](http://www.wowotech.net/memory_management/456.html) | NA |
|
||||
| 19 | [从硬件层面理解memory barrier](https://zhuanlan.zhihu.com/p/184912992) | NA |
|
||||
| 20 | [多处理器编程:从缓存一致性到内存模型](https://zhuanlan.zhihu.com/p/35386457) | NA |
|
||||
| 21 | [聊聊原子变量、锁、内存屏障那点事(2) ](https://www.sohu.com/a/250274701_467784) | NA |
|
||||
| 22 | [Spectre原理详解及分支毒化的实现](https://zhuanlan.zhihu.com/p/114680178) | NA |
|
||||
| 19 | [从硬件层面理解 memory barrier](https://zhuanlan.zhihu.com/p/184912992) | NA |
|
||||
| 20 | [多处理器编程: 从缓存一致性到内存模型](https://zhuanlan.zhihu.com/p/35386457) | NA |
|
||||
| 21 | [聊聊原子变量、锁、内存屏障那点事 (2) ](https://www.sohu.com/a/250274701_467784) | NA |
|
||||
| 22 | [Spectre 原理详解及分支毒化的实现](https://zhuanlan.zhihu.com/p/114680178) | NA |
|
||||
| 23 | [Lecture 11: Memory Data Flow Technique](http://home.eng.iastate.edu/~zzhang/courses/cpre585_f03/slides/lecture11.pdf) | NA |
|
||||
| 24 | [CPU 乱序执行与问题](https://blog.csdn.net/lizhihaoweiwei/article/details/50562732) | NA |
|
||||
| 25 | [store-queue VS store-buffer](https://stackoverflow.com/questions/24975540/what-is-the-difference-between-a-store-queue-and-a-store-buffer) | NA |
|
||||
| 26 | [《大话处理器》Cache一致性协议之MESI](https://blog.csdn.net/muxiqingyang/article/details/6615199) | NA |
|
||||
| 27 | [并发吹剑录(一)：CPU缓存一致性协议MESI](https://zhuanlan.zhihu.com/p/351550104) | NA |
|
||||
| 26 | [《大话处理器》Cache 一致性协议之 MESI](https://blog.csdn.net/muxiqingyang/article/details/6615199) | NA |
|
||||
| 27 | [并发吹剑录 (一):CPU 缓存一致性协议 MESI](https://zhuanlan.zhihu.com/p/351550104) | NA |
|
||||
| 28 | [缓存一致性协议 MESI(转载)](https://zhuanlan.zhihu.com/p/147704505) | NA |
|
||||
| 29 | [CPU缓存一致性保障原理](https://zhuanlan.zhihu.com/p/54876718) | NA |
|
||||
| 30 | [Cache一致性的那些事儿 (3)--Directory方案](https://zhuanlan.zhihu.com/p/419722803) | NA |
|
||||
| 31 | [CPU缓存一致性协议MESI](https://www.cnblogs.com/yanlong300/p/8986041.html)<br>[知乎](https://zhuanlan.zhihu.com/p/79777058) | NA |
|
||||
| 32 | [【并发编程】MESI--CPU缓存一致性协议](https://zhuanlan.zhihu.com/p/112605471) | NA |
|
||||
| 29 | [CPU 缓存一致性保障原理](https://zhuanlan.zhihu.com/p/54876718) | NA |
|
||||
| 30 | [Cache 一致性的那些事儿 (3)--Directory 方案](https://zhuanlan.zhihu.com/p/419722803) | NA |
|
||||
| 31 | [CPU 缓存一致性协议 MESI](https://www.cnblogs.com/yanlong300/p/8986041.html)<br>[知乎](https://zhuanlan.zhihu.com/p/79777058) | NA |
|
||||
| 32 | [【并发编程】MESI--CPU 缓存一致性协议](https://zhuanlan.zhihu.com/p/112605471) | NA |
|
||||
| 33 | [MESI 缓存一致性协议引发的一些思考](https://zhuanlan.zhihu.com/p/435009820) | NA |
|
||||
| 34 | [MESI Cache Coherency Protocol](https://www.scss.tcd.ie/Jeremy.Jones/vivio/caches/MESIHelp.htm?utm_source=wechat_session&utm_medium=social&utm_oi=714537833427136512) | 一个非常好的模拟网站, 模拟各种操作后, 多核之间 cache 和总线的交互以及状态变换 |
|
||||
| 35 | [解密内存屏障 (注释补充)](https://www.cnblogs.com/straybirds/p/8856726.html) | 从各种例子触发, 讲解①内存屏障, ②编译时内存乱序访问, ③运行时内存乱序访问, 摘自《程序员》, 2014/06, 作者: 梁国栋（搜狐畅游技术专家) |
|
||||
| 35 | [解密内存屏障 (注释补充)](https://www.cnblogs.com/straybirds/p/8856726.html) | 从各种例子触发, 讲解①内存屏障, ②编译时内存乱序访问, ③运行时内存乱序访问, 摘自《程序员》, 2014/06, 作者: 梁国栋 (搜狐畅游技术专家) |
|
||||
| 36 | [内存屏障详解](https://blog.csdn.net/weixin_39094034/article/details/123773446) | 讲解了 store buffer, Invalidate Queues 所解决的问题以及导致的内存可见性问题 |
|
||||
| 37 | [Volatile：内存屏障原理应该没有比这篇文章讲的更清楚了](https://www.bilibili.com/read/cv7429219/) | 提到了一个关键的点: ① 使用了 store buffer 后, 这两个操作是异步的. 这在多线程环境中, 有些情况下是可以接受的, 但是有些情况是不可接受的, 为了让程序员有能力根据业务需要达到同步完成, 就设计了内存屏障. ② 为什么要插入屏障?本质是业务层面不能接受写 store buffer 与刷回内存这两个异步操作产生的哪怕是极少的延迟, 即对内存可见性的要求极高. |
|
||||
| 37 | [Volatile:内存屏障原理应该没有比这篇文章讲的更清楚了](https://www.bilibili.com/read/cv7429219/) | 提到了一个关键的点: ① 使用了 store buffer 后, 这两个操作是异步的. 这在多线程环境中, 有些情况下是可以接受的, 但是有些情况是不可接受的, 为了让程序员有能力根据业务需要达到同步完成, 就设计了内存屏障. ② 为什么要插入屏障? 本质是业务层面不能接受写 store buffer 与刷回内存这两个异步操作产生的哪怕是极少的延迟, 即对内存可见性的要求极高. |
|
||||
| 38 | [理解内存屏障 | 《内存屏障就像版本控制一样》](https://zhuanlan.zhihu.com/p/491157678) | Preshing 先生编写的广受好评的文章 [Memory Barriers Are Like Source Control Operations](https://preshing.com/20120710/memory-barriers-are-like-source-control-operations) 的中文译文. |
|
||||
| 39 | [你应该了解的 memory barrier 背后细节](https://blog.hidva.com/2018/12/05/whymb) | 阅读 [Memory Barriers: a Hardware View for Software Hackers](http://www.rdrop.com/~paulmck/scalability/paper/whymb.2010.07.23a.pdf) 后的一些个人感悟. |
|
||||
<br>
|
||||
|
||||
* 本作品/博文 ( [AderStep-紫夜阑珊-青伶巷草 Copyright ©2013-2017](http://blog.csdn.net/gatieme) ), 由 [成坚(gatieme)](http://blog.csdn.net/gatieme) 创作.
|
||||
* 本作品 / 博文 ([AderStep - 紫夜阑珊 - 青伶巷草 Copyright ©2013-2017](http://blog.csdn.net/gatieme) ), 由 [成坚 (gatieme)](http://blog.csdn.net/gatieme) 创作.
|
||||
|
||||
* 采用<a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/4.0/"><img alt="知识共享许可协议" style="border-width:0" src="https://i.creativecommons.org/l/by-nc-sa/4.0/88x31.png" /></a><a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/4.0/">知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议</a>进行许可. 欢迎转载、使用、重新发布, 但务必保留文章署名[成坚gatieme](http://blog.csdn.net/gatieme) ( 包含链接: http://blog.csdn.net/gatieme ), 不得用于商业目的.
|
||||
* 采用 <a rel="license"href="http://creativecommons.org/licenses/by-nc-sa/4.0/"><img alt=" 知识共享许可协议 "style="border-width:0"src="https://i.creativecommons.org/l/by-nc-sa/4.0/88x31.png"/></a><a rel="license"href="http://creativecommons.org/licenses/by-nc-sa/4.0/"> 知识共享署名 - 非商业性使用 - 相同方式共享 4.0 国际许可协议 </a> 进行许可. 欢迎转载、使用、重新发布, 但务必保留文章署名 [成坚 gatieme](http://blog.csdn.net/gatieme) (包含链接: http://blog.csdn.net/gatieme), 不得用于商业目的.
|
||||
|
||||
* 基于本文修改后的作品务必以相同的许可发布. 如有任何疑问, 请与我联系.
|
||||
|
||||
* **转载请务必注明出处, 谢谢, 不胜感激**
|
||||
* ** 转载请务必注明出处, 谢谢, 不胜感激 **
|
||||
<br>
|
||||
|
||||
@@ -441,6 +441,7 @@ SGX 旨在以硬件安全为强制性保障, 不依赖于固件和软件的安
|
||||
| 2022/02/11 | David E. Box <david.e.box@linux.intel.com> | [Intel Software Defined Silicon](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=2546c60004309ede8e2d1d5341e0decd90e057bf) | TODO | v7 ☐☑✓ | [LORE v7,0/3](https://lore.kernel.org/all/20220212013252.1293396-1-david.e.box@linux.intel.com) |
|
||||
| 2022/02/24 | David E. Box <david.e.box@linux.intel.com> | [tools arch x86: Add Intel SDSi provisiong tool](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=f6d92cfc79e830d9976c69e80f97d80bae7c9c6c) | TODO | v9 ☐☑✓ | [LORE v9,0/2](https://lore.kernel.org/all/20220225012457.1661574-1-david.e.box@linux.intel.com) |
|
||||
| 2022/11/18 | David E. Box <david.e.box@linux.intel.com> | [Extend Intel On Demand (SDSi) support](https://lore.kernel.org/all/20221119002343.1281885-1-david.e.box@linux.intel.com) | TODO | v2 ☐☑✓ | [LORE v2,0/9](https://lore.kernel.org/all/20221119002343.1281885-1-david.e.box@linux.intel.com) |
|
||||
| 2023/06/23 | Mario Limonciello <mario.limonciello@amd.com> | [Add dynamic boost control support](https://lore.kernel.org/all/20230623135001.18672-1-mario.limonciello@amd.com) | 动态增强控制是一些 SOC 的一个特征, 它允许经过验证的实体向安全处理器发送命令, 以控制某些 SOC 特性, 从而提高性能. 这是通过一种机制实现的, 用户空间应用程序将通过 IOCTL 接口使用随机数和密钥交换进行身份验证. 身份验证完成后, 应用程序可以与安全处理器交换签名消息, 并且两端都可以验证传输的数据. 该系列包括一个可以在实际硬件上运行的测试套件, 以确保通信按预期工作. 这也可以用于对通信路径进行建模的应用程序. 介绍了两个用于读取 PSP 引导加载程序版本和 TEE 版本的 sysfs 文件, 这两个文件可以作为调试通信问题的有用数据点. 参见 phoronix 报道 [AMD Dynamic Boost Control Feature Set For Introduction In Linux 6.6](https://www.phoronix.com/news/AMD-Dynamic-Boost-Control-66) | v5 ☐☑✓ | [LORE v5,0/11](https://lore.kernel.org/all/20230623135001.18672-1-mario.limonciello@amd.com)|
|
||||
|
||||
|
||||
## 1.10 x86_32
|
||||
@@ -566,7 +567,7 @@ TLB entry shootdown 常常或多或少的带来一些性能问题.
|
||||
| 2016/10/24 | Marc Zyngier <marc.zyngier@arm.com> | [arm/arm64: KVM: Perform local TLB invalidation when multiplexing vcpus on a single CPU](https://patchwork.kernel.org/project/kvm/patch/1477323088-18768-1-git-send-email-marc.zyngier@arm.com) | KVM 当 guest 在运行的时候, 避免 tlbi 广播. | RFC v1 ☐ | [Patchwork RTC](https://lore.kernel.org/linux-arm-kernel/1603331829-33879-1-git-send-email-zhangshaokun@hisilicon.com) |
|
||||
| 2020/02/23 | Andrea Arcangeli <aarcange@redhat.com> | [arm64: tlb: skip tlbi broadcast v2](https://lore.kernel.org/all/20200223192520.20808-1-aarcange@redhat.com) |20200223192520.20808-1-aarcange@redhat.com | v1 ☐ | [LORE](https://lore.kernel.org/all/20200223192520.20808-1-aarcange@redhat.com) |
|
||||
| 2022/09/13 | Joe Damato <jdamato@fastly.com> | [mm: Track per-task tlb events](https://lore.kernel.org/all/1663120270-2673-1-git-send-email-jdamato@fastly.com) | 通过检查 `/proc/interrupts`, 可以在每个 CPU 的基础上测量 TLB shootdown 事件. 如果 CONFIG_DEBUG_TLBFLUSH 被启用, 关于 TLB 事件的进一步信息可以从 `/proc/vmstat` 中获取, 但是这些信息是系统范围的. 这些信息是有用的, 但是在一个有许多任务的繁忙系统上, 很难消除 TLB shootdown 事件的来源的模糊性. 这组补丁跟踪每个任务的这些信息可以使开发人员修复或调整用户空间分配器, 以减少 IPI 的数量并提高应用程序性能. 为 task_struct 和 signal_struct 添加了两个新字段, 以帮助跟踪 TLB 事件:<br>1. ngtlbflush: 生成 TLB flush 的数量.<br>2. nrtlbflush: 收到 TLB flush 的数量.<br> 这些统计数据被导出到 `/proc/[pid]/stat` 中, 与类似的指标 (如 min_flt 和 maj_flt) 一起进行分析. | v1 ☐☑✓ | [LORE v1,0/1](https://lore.kernel.org/all/1663120270-2673-1-git-send-email-jdamato@fastly.com) |
|
||||
| 2023/03/12 | Yair Podemsky <ypodemsk@redhat.com> | [send tlb_remove_table_smp_sync IPI only to necessary CPUs](https://lore.kernel.org/all/20230312080945.14171-1-ypodemsk@redhat.com) | 目前, tlb_remove_table_smp_sync() 将 IPI 被不分青红皂白地发送到所有 CPU, 这会导致不必要的工作和延迟, 在实时用例和隔离的 CPU 中尤为值得注意, 此补丁将限制此 IPI 仅发送到引用受影响 mm 的 cpu, 并且当前在内核空间中. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20230312080945.14171-1-ypodemsk@redhat.com)<br>*-*-*-*-*-*-*-* <br>[LORE v1,0/3](https://lore.kernel.org/r/20230404134224.137038-1-ypodemsk@redhat.com) |
|
||||
| 2023/03/12 | Yair Podemsky <ypodemsk@redhat.com> | [send tlb_remove_table_smp_sync IPI only to necessary CPUs](https://lore.kernel.org/all/20230312080945.14171-1-ypodemsk@redhat.com) | 目前, tlb_remove_table_smp_sync() 将 IPI 被不分青红皂白地发送到所有 CPU, 这会导致不必要的工作和延迟, 在实时用例和隔离的 CPU 中尤为值得注意, 此补丁将限制此 IPI 仅发送到引用受影响 mm 的 cpu, 并且当前在内核空间中. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20230312080945.14171-1-ypodemsk@redhat.com)<br>*-*-*-*-*-*-*-* <br>[LORE v1,0/3](https://lore.kernel.org/r/20230404134224.137038-1-ypodemsk@redhat.com)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/2](https://lore.kernel.org/r/20230620144618.125703-1-ypodemsk@redhat.com) |
|
||||
|
||||
|
||||
> 注: x86 由于没有 tlb IS 方案, 因此只能采用 IPI 的方式来完成 TLB shootdown.
|
||||
@@ -1129,6 +1130,14 @@ openEuler 提供了 [openEuler/prefetch_tuning](https://gitee.com/openeuler/pref
|
||||
| 2023/01/13 | Wyes Karny <wyes.karny@amd.com> | [amd_pstate: Add guided autonomous mode support](https://lore.kernel.org/all/20230113052141.2874296-1-wyes.karny@amd.com) | [AMD Updates P-State"Guided Autonomous Mode"Support For Linux](https://www.phoronix.com/news/AMD-Guided-Auto-Mode-v2) | v2 ☐☑✓ | [LORE v2,0/6](https://lore.kernel.org/all/20230113052141.2874296-1-wyes.karny@amd.com) |
|
||||
|
||||
|
||||
## 6.13 Device
|
||||
-------
|
||||
|
||||
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|
||||
|:---:|:----:|:---:|:----:|:---------:|:----:|
|
||||
| 2023/07/10 | Mina Almasry <almasrymina@google.com> | [Device Memory TCP](https://lore.kernel.org/all/20230710223304.1174642-1-almasrymina@google.com) | 通过该方案, 我们能够通过直接从设备存储器发送和接收数据, 达到约96.6%的线路速率. 参见 [Google Posts Experimental Linux Code For "Device Memory TCP" - Network To/From Accelerator RAM](https://www.phoronix.com/news/Linux-Device-Memory-TCP). | v1 ☐☑✓ | [LORE v1,0/10](https://lore.kernel.org/all/20230710223304.1174642-1-almasrymina@google.com) |
|
||||
|
||||
|
||||
|
||||
<br>
|
||||
|
||||
|
||||
@@ -734,7 +734,7 @@ Intel 编译器随后也切到 LLVM 框架, 参见 [Intel Fully Embracing LLVM F
|
||||
|
||||
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|
||||
|:---:|:----:|:---:|:----:|:---------:|:----:|
|
||||
| 2023/06/12 | Peter Zijlstra <peterz@infradead.org> | [Scope-based Resource Management](https://lore.kernel.org/all/20230612090713.652690195@infradead.org) | [Scope-based resource management for the kernel](https://lwn.net/Articles/934679) | v3 ☐☑✓ | [LORE v3,0/57](https://lore.kernel.org/all/20230612090713.652690195@infradead.org) |
|
||||
| 2023/06/12 | Peter Zijlstra <peterz@infradead.org> | [Scope-based Resource Management](https://lore.kernel.org/all/20230612090713.652690195@infradead.org) | [Scope-based resource management for the kernel](https://lwn.net/Articles/934679) 以及 [Scope-Based Resource Management Infrastructure Merged For Linux 6.5](https://www.phoronix.com/news/Linux-6.5-Scope-Resource-Manage). | v3 ☐☑✓ | [LORE v3,0/57](https://lore.kernel.org/all/20230612090713.652690195@infradead.org) |
|
||||
|
||||
|
||||
# 14 FTRACE
|
||||
|
||||
@@ -411,7 +411,7 @@ Lockdep 跟踪锁的获取顺序, 以检测死锁, 以及 IRQ 和 IRQ 启用/禁
|
||||
|
||||
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|
||||
|:----:|:----:|:---:|:----:|:---------:|:----:|
|
||||
| 2022/05/04 | Byungchul Park <byungchul.park@lge.com> | [DEPT(Dependency Tracker)](https://lore.kernel.org/all/1651652269-15342-1-git-send-email-byungchul.park@lge.com) | 一种死锁检测工具, 通过跟踪等待/事件而不是锁的获取顺序来检测死锁的可能性, 试图覆盖所有锁(spinlock, mutex, rwlock, seqlock, rwsem)以及同步机制(包括 wait_for_completion, PG_locked, PG_writeback, swait/wakeup 等). | v6 ☐☑✓ | [RFC 00/14](https://lore.kernel.org/lkml/1643078204-12663-1-git-send-email-byungchul.park@lge.com)<br>*-*-*-*-*-*-*-* <br>[LORE v6,0/21](https://lore.kernel.org/all/1651652269-15342-1-git-send-email-byungchul.park@lge.com)<br>*-*-*-*-*-*-*-* <br>[LORE v7,0/23](https://lore.kernel.org/r/1673235231-30302-1-git-send-email-byungchul.park@lge.com)<br>*-*-*-*-*-*-*-* <br>[LORE v8,0/25](https://lore.kernel.org/r/1674782358-25542-1-git-send-email-max.byungchul.park@gmail.com)<br>*-*-*-*-*-*-*-* <br>[LORE v9,0/25](https://lore.kernel.org/r/1675154394-25598-1-git-send-email-max.byungchul.park@gmail.com) |
|
||||
| 2022/05/04 | Byungchul Park <byungchul.park@lge.com> | [DEPT(Dependency Tracker)](https://lore.kernel.org/all/1651652269-15342-1-git-send-email-byungchul.park@lge.com) | 一种死锁检测工具, 通过跟踪等待/事件而不是锁的获取顺序来检测死锁的可能性, 试图覆盖所有锁(spinlock, mutex, rwlock, seqlock, rwsem)以及同步机制(包括 wait_for_completion, PG_locked, PG_writeback, swait/wakeup 等). | v6 ☐☑✓ | [RFC 00/14](https://lore.kernel.org/lkml/1643078204-12663-1-git-send-email-byungchul.park@lge.com)<br>*-*-*-*-*-*-*-* <br>[LORE v6,0/21](https://lore.kernel.org/all/1651652269-15342-1-git-send-email-byungchul.park@lge.com)<br>*-*-*-*-*-*-*-* <br>[LORE v7,0/23](https://lore.kernel.org/r/1673235231-30302-1-git-send-email-byungchul.park@lge.com)<br>*-*-*-*-*-*-*-* <br>[LORE v8,0/25](https://lore.kernel.org/r/1674782358-25542-1-git-send-email-max.byungchul.park@gmail.com)<br>*-*-*-*-*-*-*-* <br>[LORE v9,0/25](https://lore.kernel.org/r/1675154394-25598-1-git-send-email-max.byungchul.park@gmail.com)<br>*-*-*-*-*-*-*-* <br>[LORE v10,0/25](https://lore.kernel.org/r/20230626115700.13873-1-byungchul@sk.com)<br>*-*-*-*-*-*-*-* <br>[LORE v10,0/25](https://lore.kernel.org/r/20230703094752.79269-1-byungchul@sk.com) |
|
||||
| 2022/09/15 | 刘顺 | [OSPP 2022: Add lite-lockdep as a lightweight lock validator](https://gitee.com/openeuler/kernel/issues/I5R8DS) | openEuler 开源之夏轻量级死锁检测特性. 参考了 [Low-overhead deadlock prediction](https://dl.acm.org/doi/10.1145/3377811.3380367), [PDF](https://web.cs.ucla.edu/~palsberg/paper/icse20.pdf) | ☐☑✓ | [gitee, PR](https://gitee.com/openeuler/kernel/pulls/112) |
|
||||
|
||||
|
||||
|
||||
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
@@ -195,16 +195,17 @@ https://www.latexlive.com
|
||||
|
||||
|
||||
|
||||
[[LSF/MM/BFP TOPIC] Storage: Copy Offload](https://lkml.kernel.org/linux-block/f0e19ae4-b37a-e9a3-2be7-a5afb334a5c3@nvidia.com)
|
||||
[LSFMM: Copy offload](https://lwn.net/Articles/548347)
|
||||
[Storage: Xcopy Offload](https://blog.csdn.net/flyingnosky/article/details/123533554)
|
||||
|
||||
|
||||
|
||||
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|
||||
|:---:|:----:|:---:|:----:|:---------:|:----:|
|
||||
| 2014/05/28 | Martin K. Petersen <martin.petersen@oracle.com> | [Copy offload](https://lore.kernel.org/all/1401335565-29865-1-git-send-email-martin.petersen@oracle.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/1401335565-29865-1-git-send-email-martin.petersen@oracle.com) |
|
||||
| 2022/11/23 | Nitesh Shetty <nj.shetty@samsung.com> | [Implement copy offload support](https://lore.kernel.org/all/20221123055827.26996-1-nj.shetty@samsung.com) | TODO | v5 ☐☑✓ | [LORE v5,0/10](https://lore.kernel.org/all/20221123055827.26996-1-nj.shetty@samsung.com) |
|
||||
| 2014/05/28 | Martin K. Petersen <martin.petersen@oracle.com> | [Copy offload](https://lore.kernel.org/all/1401335565-29865-1-git-send-email-martin.petersen@oracle.com) | [Storage: Xcopy Offload](https://blog.csdn.net/flyingnosky/article/details/123533554) | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/1401335565-29865-1-git-send-email-martin.petersen@oracle.com) |
|
||||
| 2022/11/23 | Nitesh Shetty <nj.shetty@samsung.com> | [Implement copy offload support](https://lore.kernel.org/all/20221123055827.26996-1-nj.shetty@samsung.com) | [[LSF/MM/BFP TOPIC] Storage: Copy Offload](https://lkml.kernel.org/linux-block/f0e19ae4-b37a-e9a3-2be7-a5afb334a5c3@nvidia.com), [LSFMM: Copy offload](https://lwn.net/Articles/548347), [Merging copy offload](https://lwn.net/Articles/935260) | v5 ☐☑✓ | [LORE v5,0/10](https://lore.kernel.org/all/20221123055827.26996-1-nj.shetty@samsung.com)<br>*-*-*-*-*-*-*-* <br>[LORE v11,0/9](https://lore.kernel.org/r/20230522104146.2856-1-nj.shetty@samsung.com) |
|
||||
|
||||
| 2023/05/22 | Jiri Olsa <jolsa@kernel.org> | [[RFC,stable,5.4,1/8] uaccess: Add strict non-pagefault kernel-space read function](https://patchwork.kernel.org/project/linux-mm/patch/20230522203352.738576-2-jolsa@kernel.org/) | 749930 | v1 ☐☑ | [LORE v1,0/8](https://lore.kernel.org/r/20230522203352.738576-2-jolsa@kernel.org) |
|
||||
| 2023/05/22 | David Howells <dhowells@redhat.com> | [block: Use page pinning](https://patchwork.kernel.org/project/linux-mm/cover/20230522205744.2825689-1-dhowells@redhat.com/) | 749937 | v21 ☐☑ | [LORE v21,0/6](https://lore.kernel.org/r/20230522205744.2825689-1-dhowells@redhat.com) |
|
||||
| 2023/05/23 | Jesper Dangaard Brouer <brouer@redhat.com> | [page_pool: new approach for leak detection and shutdown phase](https://patchwork.kernel.org/project/linux-mm/cover/168485351546.2849279.13771638045665633339.stgit@firesoul/) | 750272 | v4 ☐☑ | [LORE v4,0/2](https://lore.kernel.org/r/168485351546.2849279.13771638045665633339.stgit@firesoul) |
|
||||
|
||||
|
||||
|
||||
@@ -315,7 +316,8 @@ https://www.latexlive.com
|
||||
|:---:|:----:|:---:|:----:|:---------:|:----:|
|
||||
| 2022/01/08 | Andy Lutomirski <luto@kernel.org> | [mm, sched: Rework lazy mm handling](https://lore.kernel.org/all/cover.1641659630.git.luto@kernel.org) | TODO | v1 ☐☑✓ | [LORE v1,0/23](https://lore.kernel.org/all/cover.1641659630.git.luto@kernel.org) |
|
||||
|
||||
| 2023/03/03 | Marcelo Tosatti <mtosatti@redhat.com> | [fold per-CPU vmstats remotely](https://patchwork.kernel.org/project/linux-mm/cover/20230303195841.310844446@redhat.com/) | 726527 | v3 ☐☑ | [LORE v1,0/5](https://lore.kernel.org/r/20230201195013.881721887@redhat.com)<br>*-*-*-*-*-*-*-* <br>[LORE v3,0/11](https://lore.kernel.org/r/20230303195841.310844446@redhat.com)<br>*-*-*-*-*-*-*-* <br>[LORE v4,0/12](https://lore.kernel.org/r/20230305133657.255737580@redhat.com)<br>*-*-*-*-*-*-*-* <br>[LORE v5,0/12](https://lore.kernel.org/r/20230313162507.032200398@redhat.com)<br>*-*-*-*-*-*-*-* <br>[LORE v7,0/13](https://lore.kernel.org/r/20230320180332.102837832@redhat.com) |
|
||||
| 2023/03/03 | Marcelo Tosatti <mtosatti@redhat.com> | [fold per-CPU vmstats remotely](https://patchwork.kernel.org/project/linux-mm/cover/20230303195841.310844446@redhat.com/) | 726527 | v3 ☐☑ | [LORE v1,0/5](https://lore.kernel.org/r/20230201195013.881721887@redhat.com)<br>*-*-*-*-*-*-*-* <br>[LORE v3,0/11](https://lore.kernel.org/r/20230303195841.310844446@redhat.com)<br>*-*-*-*-*-*-*-* <br>[LORE v4,0/12](https://lore.kernel.org/r/20230305133657.255737580@redhat.com)<br>*-*-*-*-*-*-*-* <br>[LORE v5,0/12](https://lore.kernel.org/r/20230313162507.032200398@redhat.com)<br>*-*-*-*-*-*-*-* <br>[LORE v7,0/13](https://lore.kernel.org/r/20230320180332.102837832@redhat.com)<br>*-*-*-*-*-*-*-* <br>[LORE v8,0/13](https://lore.kernel.org/r/20230515180015.016409657@redhat.com) |
|
||||
|
|
||||
|
||||
| 2023/03/06 | James Houghton <jthoughton@google.com> | [mm: rmap: merge HugeTLB mapcount logic with THPs](https://patchwork.kernel.org/project/linux-mm/cover/20230306230004.1387007-1-jthoughton@google.com/) | 727125 | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/r/20230306230004.1387007-1-jthoughton@google.com) |
|
||||
| 2023/03/08 | Mike Rapoport <rppt@kernel.org> | [Prototype for direct map awareness in page allocator](https://patchwork.kernel.org/project/linux-mm/cover/20230308094106.227365-1-rppt@kernel.org/) | 727808 | v1 ☐☑ | [LORE v1,0/5](https://lore.kernel.org/r/20230308094106.227365-1-rppt@kernel.org) |
|
||||
@@ -482,6 +484,47 @@ BPF verifiery 已经做了很多工作来尽量确保加载进 kernel 的 BPF pr
|
||||
|
||||
|
||||
|
||||
| 2023/05/04 | Florent Revest <revest@chromium.org> | [MDWE without inheritance](https://patchwork.kernel.org/project/linux-mm/cover/20230504170942.822147-1-revest@chromium.org/) | 745049 | v1 ☐☑ | [LORE v1,0/4](https://lore.kernel.org/r/20230504170942.822147-1-revest@chromium.org)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/5](https://lore.kernel.org/r/20230517150321.2890206-1-revest@chromium.org) |
|
||||
|
||||
|
||||
uclamp_min造成的任务 misfit 并不意味着 cpu overutiled, 因为这仅仅是 uclamp_min 的约束, 具有小 util_avg 的任务可能不适合所在高 capacity 的 cpu. 在 util_filts_cpu() 中添加一个新状态, 以反映任务适合 cpu 的情况, 但 uclamp_min 提示除外, 这是一个性能要求. 使用 -1 来反映 CPU 不适合只是因为 uclamp_min, 所以我们可以使用这个新值来采取额外的操作, 以选择与 uclamp_minhint 不匹配的最佳 CPU. 当 util_filts_cpu() 返回 -1 时, 我们将继续寻找一种可能的性能更好的 cpu, 它用 capacity_orig_of() - thermal_load_avg 代替容量反转检测来检测容量反转.
|
||||
|
||||
|
||||
| 2023/05/08 | zhaoyang.huang <zhaoyang.huang@unisoc.com> | [Optimization of CMA allocation and reclaiming](https://patchwork.kernel.org/project/linux-mm/cover/1683538383-19685-1-git-send-email-zhaoyang.huang@unisoc.com/) | 745744 | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/r/1683538383-19685-1-git-send-email-zhaoyang.huang@unisoc.com) |
|
||||
| 2023/05/15 | Jeff Xu <jeffxu@chromium.org> | [Memory Mapping (VMA) protection using PKU - set 1](https://patchwork.kernel.org/project/linux-mm/cover/20230515130553.2311248-1-jeffxu@chromium.org/) | 747576 | v1 ☐☑ | [LORE v1,0/6](https://lore.kernel.org/r/20230515130553.2311248-1-jeffxu@chromium.org)<br>*-*-*-*-*-*-*-* <br>[LORE v1,0/6](https://lore.kernel.org/r/20230519011915.846407-1-jeffxu@chromium.org)<br>*-*-*-*-*-*-*-* <br>[LORE v1,0/6](https://lore.kernel.org/r/20230519011915.846407-1-jeffxu@chromium.org) |
|
||||
|
|
||||
| 2023/05/19 | Joel Fernandes <joel@joelfernandes.org> | [Optimize mremap during mutual alignment within PMD](https://patchwork.kernel.org/project/linux-mm/cover/20230519190934.339332-1-joel@joelfernandes.org/) | 749361 | v2 ☐☑ | [LORE v2,0/4](https://lore.kernel.org/r/20230519190934.339332-1-joel@joelfernandes.org)<br>*-*-*-*-*-*-*-* <br>[LORE v3,0/6](https://lore.kernel.org/r/20230524153239.3036507-1-joel@joelfernandes.org) |
|
||||
| 2023/06/13 | Peter Xu <peterx@redhat.com> | [mm/gup: Unify hugetlb, speed up thp](https://patchwork.kernel.org/project/linux-mm/cover/20230613215346.1022773-1-peterx@redhat.com/) | 756868 | v1 ☐☑ | [LORE v1,0/7](https://lore.kernel.org/r/20230613215346.1022773-1-peterx@redhat.com)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/8](https://lore.kernel.org/r/20230619231044.112894-1-peterx@redhat.com)<br>*-*-*-*-*-*-*-* <br>[LORE v4,0/8](https://lore.kernel.org/r/20230628215310.73782-1-peterx@redhat.com |
|
||||
| 2023/06/16 | Huang, Ying <ying.huang@intel.com> | [memory tiering: calculate abstract distance based on ACPI HMAT](https://patchwork.kernel.org/project/linux-mm/cover/20230616070538.190042-1-ying.huang@intel.com/) | 757742 | v1 ☐☑ | [LORE v1,0/4](https://lore.kernel.org/r/20230616070538.190042-1-ying.huang@intel.com) |
|
||||
| 2023/06/16 | Mike Rapoport <rppt@kernel.org> | [mm: jit/text allocator](https://patchwork.kernel.org/project/linux-mm/cover/20230616085038.4121892-1-rppt@kernel.org/) | 757762 | v2 ☐☑ | [LORE v2,0/12](https://lore.kernel.org/r/20230616085038.4121892-1-rppt@kernel.org) |
|
||||
| 2023/06/16 | Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> | [Add support for DAX vmemmap optimization for ppc64](https://patchwork.kernel.org/project/linux-mm/cover/20230616110826.344417-1-aneesh.kumar@linux.ibm.com/) | 757832 | v2 ☐☑ | [LORE v2,0/16](https://lore.kernel.org/r/20230616110826.344417-1-aneesh.kumar@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v4,0/13](https://lore.kernel.org/r/20230710160842.56300-1-aneesh.kumar@linux.ibm.com) |
|
||||
| 2023/06/16 | GONG, Ruiqi <gongruiqi@huaweicloud.com> | [Randomized slab caches for kmalloc()](https://patchwork.kernel.org/project/linux-mm/cover/20230616111843.3677378-1-gongruiqi@huaweicloud.com/) | 757836 | v3 ☐☑ | [LORE v3,0/1](https://lore.kernel.org/r/20230616111843.3677378-1-gongruiqi@huaweicloud.com) |
|
||||
| 2023/06/16 | Arjun Roy <arjunroy.kdev@gmail.com> | [[net-next,v2] tcp: Use per-vma locking for receive zerocopy](https://patchwork.kernel.org/project/linux-mm/patch/20230616193427.3908429-1-arjunroy.kdev@gmail.com/) | 757998 | v2 ☐☑ | [LORE v2,0/1](https://lore.kernel.org/r/20230616193427.3908429-1-arjunroy.kdev@gmail.com) |
|
||||
| 2023/06/19 | Alexey Romanov <avromanov@sberdevices.ru> | [Add obj allocated counter for subpages](https://patchwork.kernel.org/project/linux-mm/cover/20230619143506.45253-1-avromanov@sberdevices.ru/) | 758404 | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/r/20230619143506.45253-1-avromanov@sberdevices.ru) |
|
||||
| 2023/06/20 | Hugh Dickins <hughd@google.com> | [mm: free retracted page table by RCU](https://patchwork.kernel.org/project/linux-mm/cover/54cb04f-3762-987f-8294-91dafd8ebfb0@google.com/) | 758573 | v2 ☐☑ | [LORE v2,0/12](https://lore.kernel.org/r/54cb04f-3762-987f-8294-91dafd8ebfb0@google.com) |
|
||||
| 2023/06/21 | Matthew Wilcox <willy@infradead.org> | [Remove pagevecs](https://patchwork.kernel.org/project/linux-mm/cover/20230621164557.3510324-1-willy@infradead.org/) | 759217 | v1 ☐☑ | [LORE v1,0/13](https://lore.kernel.org/r/20230621164557.3510324-1-willy@infradead.org) |
|
||||
| 2023/06/21 | Yuanchu Xie <yuanchu@google.com> | [mm: working set reporting](https://patchwork.kernel.org/project/linux-mm/cover/20230621180454.973862-1-yuanchu@google.com/) | 759245 | v2 ☐☑ | |
|
||||
| 2023/06/22 | Kasireddy, Vivek <vivek.kasireddy@intel.com> | [udmabuf: Add back support for mapping hugetlb pages](https://patchwork.kernel.org/project/linux-mm/cover/20230622072710.3707315-1-vivek.kasireddy@intel.com/) | 759373 | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/r/20230622072710.3707315-1-vivek.kasireddy@intel.com) |
|
||||
| 2023/06/22 | Qi Zheng <zhengqi.arch@bytedance.com> | [use refcount+RCU method to implement lockless slab shrink](https://patchwork.kernel.org/project/linux-mm/cover/20230622085335.77010-1-zhengqi.arch@bytedance.com/) | 759412 | v1 ☐☑ | [LORE v1,0/29](https://lore.kernel.org/r/20230622085335.77010-1-zhengqi.arch@bytedance.com) |
|
||||
| 2023/06/22 | Ryan Roberts <ryan.roberts@arm.com> | [Transparent Contiguous PTEs for User Mappings](https://patchwork.kernel.org/project/linux-mm/cover/20230622144210.2623299-1-ryan.roberts@arm.com/) | 759528 | v1 ☐☑ | [LORE v1,0/14](https://lore.kernel.org/r/20230622144210.2623299-1-ryan.roberts@arm.com) |
|
||||
| 2023/06/26 | Ryan Roberts <ryan.roberts@arm.com> | [variable-order, large folios for anonymous memory](https://patchwork.kernel.org/project/linux-mm/cover/20230626171430.3167004-1-ryan.roberts@arm.com/) | 760361 | v1 ☐☑ | [LORE v1,0/10](https://lore.kernel.org/r/20230626171430.3167004-1-ryan.roberts@arm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v4,0/5](https://lore.kernel.org/r/20230726095146.2826796-1-ryan.roberts@arm.com) |
|
||||
| 2023/06/27 | zhaoyang.huang <zhaoyang.huang@unisoc.com> | [mm: introduce statistic for inode's gen&tier](https://patchwork.kernel.org/project/linux-mm/patch/1687857438-29142-1-git-send-email-zhaoyang.huang@unisoc.com/) | 760556 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/1687857438-29142-1-git-send-email-zhaoyang.huang@unisoc.com) |
|
||||
| 2023/06/27 | Chuck Lever <cel@kernel.org> | [shmemfs stable directory offsets](https://patchwork.kernel.org/project/linux-mm/cover/168789864000.157531.11122232592994999253.stgit@manet.1015granger.net/) | 760743 | v5 ☐☑ | [LORE v5,0/3](https://lore.kernel.org/r/168789864000.157531.11122232592994999253.stgit@manet.1015granger.net) |
|
||||
| 2023/07/10 | Yajun Deng <yajun.deng@linux.dev> | [dma-contiguous: support numa CMA for specified node](https://patchwork.kernel.org/project/liux-mm/patch/20230710074944.3501810-1-yajun.deng@linux.dev/) | 763917 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20230710074944.3501810-1-ajun.deng@linux.dev)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/1](https://lore.kernel.org/r/20230711110822.1105785-1-yajun.deng@linux.dev) |
|
||||
| 2023/07/10 | Minchan Kim <minchan@kernel.org> | [zram: use frontswap for zram swap usecase](https://patchwork.kernel.org/project/linux-mm/cove/20230710221659.2473460-1-minchan@kernel.org/) | 764176 | v1 ☐☑ | [LORE v1,0/3](https://lore.kernel.org/r/20230710221659.2473460-1-minchan@kerne.org) |
|
||||
| 2023/07/20 | Yosry Ahmed <yosryahmed@google.com> | [memory recharging for offline memcgs](https://patchwork.kernel.org/project/linux-mm/cover/20230720070825.992023-1-yosryahmed@google.com/) | 767656 | v1 ☐☑ | [LORE v1,0/8](https://lore.kernel.org/r/20230720070825.992023-1-yosryahmed@google.com) |
|
||||
| 2023/07/23 | Hyeonggon Yoo <42.hyeyoo@gmail.com> | [An attempt to improve SLUB on NUMA / under memory pressure](https://patchwork.kernel.org/project/linux-mm/cover/20230723190906.4082646-1-42.hyeyoo@gmail.com/) | 768670 | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/r/20230723190906.4082646-1-42.hyeyoo@gmail.com) |
|
||||
| 2023/07/23 | Hugh Dickins <hughd@google.com> | [[v3,11/13,fix] mm/khugepaged: delete khugepaged_collapse_pte_mapped_thps(): fix](https://patchwork.kernel.org/project/linux-mm/patch/bfc6cab2-497f-32bf-dd5-98dc1987e4a9@google.com/) | 768689 | v3 ☐☑ | [LORE v3,0/13](https://lore.kernel.org/r/bfc6cab2-497f-32bf-dd5-98dc1987e4a9@google.com) |
|
||||
| 2023/07/24 | Zhongkun He <hezhongkun.hzk@bytedance.com> | [zram: memcg accounting](https://patchwork.kernel.org/project/linux-mm/cover/20230724062143.2244078-1-hezhongkun.hzk@bytedance.com/) | 768727 | v2 ☐☑ | [LORE v2,0/2](https://lore.kernel.org/r/20230724062143.2244078-1-hezhongkun.hzk@bytedance.com) |
|
||||
| 2023/07/24 | Mark Brown <broonie@kernel.org> | [arm64/gcs: Provide support for GCS in userspace](https://patchwork.kernel.org/project/linux-mm/cover/20230724-arm64-gcs-v2-0-dc2c1d44c2eb@kernel.org/) | 768889 | v2 ☐☑ | [LORE v2,0/35](https://lore.kernel.org/r/20230724-arm64-gcs-v2-0-dc2c1d44c2eb@kernel.org) |
|
||||
| 2023/07/24 | Qi Zheng <zhengqi.arch@bytedance.com> | [use refcount+RCU method to implement lockless slab shrink](https://patchwork.kernel.org/project/linux-mm/cover/20230724094354.90817-1-zhengqi.arch@bytedance.com/) | 768800 | v2 ☐☑ | [LORE v2,0/47](https://lore.kernel.org/r/20230724094354.90817-1-zhengqi.arch@bytedance.com)<br>*-*-*-*-*-*-*-* <br>[LORE v3,0/49](https://lore.kernel.org/r/20230727080502.77895-1-zhengqi.arch@bytedance.com) |
|
||||
|
||||
| 2023/07/27 | Ryan Roberts <ryan.roberts@arm.com> | [Optimize large folio interaction with deferred split](https://patchwork.kernel.org/project/linux-mm/cover/20230727141837.3386072-1-ryan.roberts@arm.com/) | 770154 | v4 ☐☑ | [LORE v4,0/3](https://lore.kernel.org/r/20230727141837.3386072-1-ryan.roberts@arm.com) |
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
这是新空闲平衡优化 [Limit the scan depth to find the busiest sched group during newidle balance](https://lore.kernel.org/all/cover.1686554037.git.yu.c.chen@intel.com) 的新版本. 它旨在降低新空闲平衡的成本, 在一些高核计数系统上, 新空闲平衡被发现占用了明显的 CPU 周期. 例如, 当在 Intel Sapphire Rapids 上运行 sqlite 时, 它有 2 x 56C/112T = 224 个 cpu: newidle_balance 以及 update_sd_lb_stats 的热点达到 5% 以上. 为了减少这一开销, Tim 提出的问题启发了我们进行优化:<br>1. 第一个是 ILB_UTIL. 建议在 update_sd_lb_stats() 中限制扫描深度. 扫描深度取决于该调度域的总体利用率. 利用率越高, update_sd_lb_stats() 扫描的数据就越少. 亦然.<br>2. 第二个是 ILB_FAST. 与其总是在 update_sd_lb_stats() 中查找最繁忙的组, 不如降低标准并尝试查找相对繁忙的组. 当本地组为 group_has_spare 时, ILB_FAST 生效. 因为当有许多 cpu 并发地运行 newidle_balance() 时, 计划组应该有很高的空闲百分比.<br>3. 与 ILB_UTIL 和 ILB_FAST 相比, ILB_UTIL 抑制了系统繁忙时的调度组扫描. 后者在系统不忙时选择折衷的忙群. 它们相互补充, 独立工作.
|
||||
|
||||
|
||||
@@ -176,7 +176,7 @@ jeremy 很早就写了一个 pv ticketlock, 原理大概就是 vcpu 在拿锁了
|
||||
|
||||
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|
||||
|:----:|:----:|:---:|:----:|:---------:|:----:|
|
||||
| 2022/10/26 | Huang, Kai <kai.huang@intel.com> | [TDX host kernel support](https://patchwork.kernel.org/project/linux-mm/cover/cover.1666824663.git.kai.huang@intel.com/) | 689199 | v6 ☐☑ | [LORE v6,0/21](https://lore.kernel.org/r/cover.1666824663.git.kai.huang@intel.com)<br>*-*-*-*-*-*-*-* <br>[LORE v7,0/20](https://lore.kernel.org/r/cover.1668988357.git.kai.huang@intel.com)<br>*-*-*-*-*-*-*-* <br>[LORE v8,0/16](https://lore.kernel.org/r/cover.1670566861.git.kai.huang@intel.com)<br>*-*-*-*-*-*-*-* <br>[LORE v10,0/16](https://lore.kernel.org/all/cover.1678111292.git.kai.huang@intel.com) |
|
||||
| 2022/10/26 | Huang, Kai <kai.huang@intel.com> | [TDX host kernel support](https://patchwork.kernel.org/project/linux-mm/cover/cover.1666824663.git.kai.huang@intel.com/) | 689199 | v6 ☐☑ | [LORE v6,0/21](https://lore.kernel.org/r/cover.1666824663.git.kai.huang@intel.com)<br>*-*-*-*-*-*-*-* <br>[LORE v7,0/20](https://lore.kernel.org/r/cover.1668988357.git.kai.huang@intel.com)<br>*-*-*-*-*-*-*-* <br>[LORE v8,0/16](https://lore.kernel.org/r/cover.1670566861.git.kai.huang@intel.com)<br>*-*-*-*-*-*-*-* <br>[LORE v10,0/16](https://lore.kernel.org/all/cover.1678111292.git.kai.huang@intel.com)<br>*-*-*-*-*-*-*-* <br>[LORE v12,0/22](https://lore.kernel.org/r/cover.1687784645.git.kai.huang@intel.com) |
|
||||
| 2021/04/16 | Kirill A. Shutemov <kirill.shutemov@linux.intel.com> | [TDX and guest memory unmapping](https://lore.kernel.org/all/20210416154106.23721-1-kirill.shutemov@linux.intel.com) | 作者有意不考虑 TDX, 并尝试找到一种通用的方法来从主机用户空间取消 KVM 客户内存的映射. 借助页表中 PG_hwpoison 的页和 SWP_HWPOISON 的交换项:<br>1. 如果应用程序接触到 SWP_HWPOISON 映射的页面, 它将得到 SIGBUS.<br>2. 当我们将页面设置为 TD-private 时, 我们可以将页面标记为有毒的, 并用 SWP_HWPOISON 替换映射该页的所有 pte. | v1 ☐☑✓ | [LORE v1,0/13](https://lore.kernel.org/all/20210416154106.23721-1-kirill.shutemov@linux.intel.com) |
|
||||
| 2021/08/23 | Sean Christopherson <seanjc@google.com> | [KVM: mm: fd-based approach for supporting KVM guest private memory](https://lore.kernel.org/all/20210824005248.200037-1-seanjc@google.com) | 这是 Kirill 的 RFC 的延续, 通过在 `struct page` 级别跟踪客户内存来支持 TDX 客户私有内存. 这个提案是由 Andy Lutomirksi 对通过 `struct page` 进行跟踪的担忧引发的几次离线讨论的结果. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20210824005248.200037-1-seanjc@google.com) |
|
||||
| 2022/10/25 | Chao Peng <chao.p.peng@linux.intel.com> | [KVM: mm: fd-based approach for supporting KVM](https://patchwork.kernel.org/project/linux-mm/cover/20221025151344.3784230-1-chao.p.peng@linux.intel.com/) | 用于机密计算场景 (如 [Intel TDX](https://www.intel.com/content/www/us/en/developer/articles/technical/intel-trust-domain-extensions.html)) 的 KVM 客户私有内存. 本系列通过引入新的 mm 和 KVM 接口来解决 KVM 用户空间导致的崩溃问题, 因此 KVM 用户空间仍然可以通过基于 fd 的方法管理来宾内存, 但它永远不能访问来宾内存内容. | v9 ☐☑ | [LORE v9,0/8](https://lore.kernel.org/r/20221025151344.3784230-1-chao.p.peng@linux.intel.com)<br>*-*-*-*-*-*-*-* <br>[LORE v10,0/9](https://lore.kernel.org/r/20221202061347.1070246-1-chao.p.peng@linux.intel.com) |
|
||||
|
||||
Reference in New Issue
Block a user