问题标签 [tlb]

这是我所做的：

1. 用户空间进程用于malloc()在堆上分配内存并用特定模式的字符填充它，然后拼出malloc().

2. 进程 id 和内存块的地址被传递给一个内核模块，如下所示：

   }

3. 我在 Linux 内核printk()中的函数中添加了语句来跟踪由（上面的变量定义之后的第 3 行代码）handle_mm_fault()引起的页面错误。target_process_id像这样的东西：

   /li>

现在，我注意到最后一条printk()语句没有捕获任何内容。

该函数init_module是内核模块的初始化函数。使用 insmod 将其插入到正在运行的内核中...使用命令insmod module.ko pid=<processId> addr=<address>

知道可能出了什么问题吗？

考虑一个具有两级分页方案的系统，其中常规内存访问需要 150 纳秒，处理页面错误需要 8 毫秒。一条平均指令需要 100 ns 的 CPU 时间和两次内存访问。TLB命中率为90%，缺页率为万分之一。有效平均指令执行时间是多少？

这是在 GATE 2004 中提出的。为了解决这个问题，我将遵循以下概念：
T(memory access avg) = .90(150) + .1(150+150+150) = 180 (150- level1, 150- level2 和 150 内存）
T 有效 = 100+ 2* 180 + 1/10000* 8* 10^6 = 1260。

这种方法正确吗？我也有以下疑问：

1. 当 TLB 命中时不会出现页面错误，因为最常用的页面必须在内存中。这是对的吗 ？
   
2. 进程的页表大小是多少？假设一个 32 位虚拟地址，我们是否为每个进程分配一个包含 2^32 个条目的页表？分页中的内存限制是如何管理的？

请解释这些概念。

一个典型的有20%的内存指令。假设有5%的数据TLB未命中，每条需要100个周期来处理。假设每条指令需要1个周期执行，缓存中的每个内存操作1个周期，10%的数据访问是缓存未命中每个缓存未命中是 15 个周期，那么执行 1000 条指令需要多长时间。

我不知道答案，但我对 TLB 和缓存的存在感到困惑，我的印象是缓存和 TLB 是一回事？

应用程序使用虚拟内存。这是一个很好的概念，我们可以将它视为一个连续的块，而不必关心它是否在物理 RAM 中是连续的，或者它是否在硬盘上。

据我了解，虚拟地址和物理地址之间的映射是由 CPU（或至少在硬件中）使用转换后备缓冲区直接完成的。

我假设内核以某种方式维护了 TLB 的内容，但在这里我有点卡住了，所以我有 3 个问题：

查询、读写TLB内容的具体汇编指令有哪些？我不是很幸运地在谷歌上搜索与该主题相关的操作码。我刚刚找到了 INVLPG 和 TLBWI。因为我对这种深度不熟悉，所以也许我只是使用了错误的搜索词。如果您立即找到它，您使用哪些搜索词？

所有这些汇编指令都需要特权 CPU 模式吗？

TLB的初始内容是什么？如果 TLB 一开始是空的，这是否意味着操作系统的第一条汇编指令将直接映射到物理内存（因此虚拟地址 == 物理地址）？

我对以下任务有疑问。

考虑一个 IA-32 系统，其中 MMU 支持两级页表。第二级包含 1024 个页表条目，映射到 4 KB 页框。每个页表条目（两个级别）的大小为 4 个字节。系统仅支持 4 KB 页面大小。
我们想从虚拟内存中连续读取 8 MB，从字节 0 开始。我们一次读取一个字（4 个字节）
我们有一个 8 条目数据 TLB。读取上面指定的 8 MB 内存需要多少内存访问？

如果 TLB 有 4 个条目而不是 8 个条目，这会有所不同吗？

所以，我们按顺序阅读。这意味着 8MB/4B = 2M 内存访问。我们有一个两级页表。因此，2M + 2*2M = 6M 没有 TLB 的内存访问。

但我不知道如何计算包括 TLB 在内的内存访问。

谁能给我解释一下？那将非常有帮助。

我正在观察最后几个英特尔微架构（Nehalem/SB/IB 和 Haswell）。我正在尝试弄清楚发出数据请求时会发生什么（在相当简化的层面上）。到目前为止，我有一个粗略的想法：

1. 执行引擎发出数据请求
2. “内存控制”查询 L1 DTLB
3. 如果以上都未命中，现在查询 L2 TLB

此时可能会发生两件事，未命中或命中：

1. 如果命中，CPU 会按顺序尝试 L1D/L2/L3 缓存、页表和主内存/硬盘？

2. 如果它未命中 - CPU 请求（集成内存控制器？）请求检查 RAM 中保存的页表（我在那里得到了正确的 IMC 角色吗？）。

如果有人可以编辑/提供一组要点，这些要点提供 CPU 从执行引擎数据请求中所做的基本“概述”，包括

• L1 DTLB（数据 TLB）
• L2 TLB（数据+指令TLB）
• L1D Cache（数据缓存）
• 二级缓存（数据+指令缓存）
• L3缓存（数据+指令缓存）
• CPU 中控制对主存的访问的部分
• 页表

将不胜感激。我确实找到了一些有用的图像：

• http://www.realworldtech.com/wp-content/uploads/2012/10/haswell-41.png
• http://upload.wikimedia.org/wikipedia/commons/thumb/6/60/Intel_Core2_arch.svg/1052px-Intel_Core2_arch.svg.png

但他们并没有真正分离 TLB 和缓存之间的交互。

更新：我想我现在明白了，已经改变了上面的内容。TLB 只是从虚拟地址获取物理地址。如果有遗漏——我们就有麻烦了，需要检查页表。如果有命中，我们只需从 L1D 缓存开始向下遍历内存层次结构。

我一直在阅读有关将虚拟地址转换为物理地址的内容。我知道 TLB 是一个硬件缓存，位于 CPU 的内存管理单元中，包含最近访问的页面的映射。

但是，假设有一个 TLB 命中 -操作系统如何确保该页面实际上可以被进程访问（在进程分配的地址空间内）？

我相信这样做的一种方法是检查进程的页表，但这似乎违背了使用 TLB 的全部目的。有什么见解吗？

当我分析我的程序时，我发现“_raw_spin_unlock_irq”系统调用会导致 ARM Cortex A15 板上的大量 iTLB 未命中。在我仔细检查了汇编代码后，我发现“cpsie”指令可能是原因之一。因此，我编写了一个短代码来验证我的假设。

以下是我的代码：

然后我使用 perf 工具检查 iTLB 未命中，它报告：

89172 dTLB 负载未命中

5694 dTLB 存储未命中

43248 iTLB 加载未命中

去掉“cpsie i”指令后，结果为：

23453 dTLB 负载未命中

1453 dTLB 存储未命中

12035 iTLB 加载未命中

结果表明，“cpsie i”增加了 4 倍 iTLB 未命中。我使用 perf 报告对二进制代码进行了注释，69.5% 的 iTLB 未命中发生在“cpsie i”指令之后。

我很困惑为什么在“cpsie i”指令之后发生了很多 iTLB 未命中？有什么办法可以防止吗？谢谢！

Linux 将虚拟内存空间分为两部分：0x00000000 ~ 0xBFFFFFFF 和 0xC0000000 ~ 0xFFFFFFFF。正如我所读到的，所有进程共享相同的内核虚拟空间 0xC0000000 ~ 0xFFFFFFFF。

我正在尝试锁定一个 TLB 以在 ARM 架构上进行系统调用。例如，对于 raw_spin 系统调用，我从 System.map 中获得了虚拟地址 0xc04d35b0，然后我想找到对应的物理地址来锁定一个 TLB 条目。

我的问题是如何读取内核页表？谢谢！

我正在尝试验证软件 MMU。

在我得到的测试用例中，我需要检查“TLB 锁定和失效”。

我进行了测试并检查了 TLB 未命中，但我无法理解 TLB 锁定和失效的确切含义。