什么是SMP中的TLB击落？
我无法找到有关此概念的更多信息.任何好的例子都会非常感激.
我正在阅读操作系统概念,我在第8章!但是,我可以使用一些澄清,或者保证我的理解是正确的.
逻辑地址:根据本书,CPU生成逻辑地址.这到底是什么意思？(在执行生成的地址系统中..)我假设在为程序编译代码时,程序不知道代码将在何处加载到内存中.所有编译器都会设置程序布局的一般草图以及图像的布局方式,但不会为其分配任何实际地址.当程序执行时,CPU获取编译器生成的这个布局图像,并将一些地址(逻辑1)分发给从代码生成的地址.
物理地址:直到CPU生成一组逻辑地址(由基地址和偏移量组成)之后才生成物理地址.逻辑地址通过MMU或其他设备,沿着线路的某处,逻辑地址映射到物理RAM地址.
那么实际差异是什么？我可以看到一个好处.使用逻辑地址为应用程序提供了更多自由.如果物理地址是硬编码的,那么程序的成功将在很大程度上取决于物理计算机,可用的RAM地址等.
转换为物理地址的逻辑地址的使用是否会产生两个步骤而不是一对一,因此更多地超过？
然后逻辑地址在生成后驻留在哪里？它们可能存在于CPU上的寄存器中,而CPU正在为一个进程提供服务,但在它之前和之后,它们去哪里了？我理解这是依赖于实现的.我假设它们可能存储在CPU的某些特殊寄存器空间或缓冲区中,例如TLB,对吗？如果没有,那么表可能存在于实际的RAM本身中,而CPU只保存一个指针/地址到RAM中表的基地址,对吗？
看起来保持RAM中的地址对逻辑存储器地址的目的是有效的.我只能假设我的理解不正确.
内存障碍保证数据缓存一致.但是,它是否保证TLB一致？
我看到一个问题,当在线程之间传递MappedByteBuffer时,JVM(java 7更新1)有时会因内存错误(SIGBUS,SIGSEG)而崩溃.
例如
final AtomicReference<MappedByteBuffer> mbbQueue = new AtomicReference<>();
// in a background thread.
MappedByteBuffer map = raf.map(MapMode.READ_WRITE, offset, allocationSize);
Thread.yield();
while (!inQueue.compareAndSet(null, map));
// the main thread. (more than 10x faster than using map() in the same thread)
MappedByteBuffer mbb = inQueue.getAndSet(null);
没有Thread.yield()我偶尔会在force(),put()和C的memcpy()中崩溃,这些都表示我试图非法访问内存.使用Thread.yield()我没有遇到任何问题,但这听起来不是一个可靠的解决方案.
有人遇到过这个问题吗？有关TLB和内存障碍的保证吗？
编辑:操作系统是Centos 5.7,我已经看到了i7和双Xeon机器上的行为.
为什么我这样做？因为写入消息的平均时间是35-100 ns,具体取决于长度,使用普通的write()并不是那么快.如果我在当前线程中进行内存映射和清理,则需要50-130微秒,使用后台线程执行此操作需要大约3-5微秒的主线程交换缓冲区.为什么我需要交换缓冲区呢？因为我写的是很多GB数据而且ByteBuffer的大小不能超过2 GB.
处理器x86/x86_64中使用哪种寻址在L1,L2和L3(LLC)中进行缓存 - 物理或虚拟(使用PT/PTE和TLB)以及PAT(页面属性表)对它有何影响？
在这种情况下,驱动程序(内核空间)和应用程序(用户空间)之间是否存在差异？
简短回答 - 英特尔使用虚拟索引,物理标记(VIPT)L1缓存:线程之间的数据交换将用于在具有HT的一个Core上执行什么？
8-way用于定义的高速缓存中Set需要低12 bits,这在virt和phys中是相同的)有人可以解释TLB(翻译后备缓冲区)未命中和缓存未命中之间的区别吗？
我相信我发现TLB指的是某种虚拟内存地址,但我并不清楚这实际意味着什么？
我理解当一块内存(缓存行的大小)被加载到(L3？)缓存中并且如果所需的地址没有保存在当前缓存行中时,会导致缓存未命中 - 这是缓存未命中.
我是一个操作系统爱好者,我的内核运行在80486+,并且已经支持虚拟内存.
从80386开始,英特尔的x86处理器系列及其各种克隆通过分页支持虚拟内存.众所周知,当设置PG位时CR0,处理器使用虚拟地址转换.然后,CR3寄存器指向顶级页面目录,即用于将虚拟地址映射到物理地址的2-4级页表结构的根.
处理器不会为生成的每个虚拟地址查询这些表,而是将它们缓存在名为Translation Lookaside Buffer或TLB的结构中.但是,当对页表进行更改时,需要刷新TLB.在80386处理器上,此刷新将通过使用顶级页面目录地址或任务切换重新加载(MOV)来完成CR3.这应该无条件地刷新所有TLB条目.据我所知,虚拟内存系统在任何更改后总是重新加载CR3是完全有效的.
这是浪费,因为TLB现在会抛出完全好的条目,因此在80486处理器INVLPG中引入了指令.INVLPG将使与源操作数地址匹配的TLB条目无效.
然而,从Pentium Pro开始,我们还拥有全局页面,这些页面不会被移动到CR3任务切换; 和AMD x86-64 ISA表示某些高级页面表结构可能会被高速缓存而不会失效INVLPG.为了获得每个ISA所需内容和不需要内容的连贯图片,我们真的需要为80年代以来发布的大量ISA下载1000页的数据表来阅读其中的几页,即使这样,文档似乎也是如此对TLB失效特别模糊,如果TLB未正确无效,会发生什么.
为简单起见,可以假设我们正在讨论单处理器系统.此外,可以假设在更改页面结构后不需要任务切换.(因此INVLPG总是被认为至少是重新加载CR3寄存器的好选择).
基本假设是CR3每次更改页面表和页面目录后都需要重新加载,这样的系统是正确的.但是,如果想要避免不必要地冲刷TLB,则需要回答2个问题:
如果INVLPGISA支持,经过哪种更改可以安全地使用它而不是重新加载CR3？例如"如果一个取消映射一个页面框架(将相应的表条目设置为不存在),则可以始终使用INVLPG"？
在不触及CR3或执行的情况下,可以对表和目录进行哪些更改INVLPG？例如"如果一个页面根本没有映射(不存在),那么就可Present=1以为它编写一个PTE 而不用刷新TLB"？
即使在阅读了大量的ISA文档以及与INVLPGStack Overflow 相关的所有内容之后,我也不确定我在那里提供的任何一个例子.事实上,一篇值得注意的帖子马上说:"我不知道你何时应该使用它,什么时候不应该使用它." 因此,您可以提供任何特定的,正确的示例,最好是文档,以及您可以给出的IA32或x86-64.
Cache和Translation LookAside Buffer [TLB]有什么区别？
现代x86 CPU能够支持比传统4K更大的页面大小(即2MB或4MB),并且有操作系统(Linux,Windows)可以访问此功能.
上面的Microsoft链接声明大页面"提高了转换缓冲区的效率,这可以提高频繁访问的内存的性能".这对于预测大页面是否会改善任何特定情况并不是很有帮助.我对具体的,最好是量化的例子感兴趣,其中一些程序逻辑(或整个应用程序)移动使用大页面导致一些性能改进.有人有成功的故事吗？
我知道自己有一个特殊情况:使用大页面可以大大减少分支大型进程所需的时间(可能是因为需要复制的TLB记录数量减少了1000个数量级).我很感兴趣的是,在不那么奇特的场景中,大页面是否也可以带来好处.
我很难理解当翻译旁视缓冲区的前两个级别导致未命中时会发生什么？
我不确定特殊硬件电路中是否出现"页面行走",或者页表是否存储在L2/L3高速缓存中,或者它们是否只存在于主存储器中.
有人能清楚地解释一下缓存未命中,tlb未命中和页面错误之间的区别,以及它们如何影响有效的内存访问时间？