上下文切换的开销是多少？

Question

最初我认为上下文切换的开销是TLB被刷新.但是我刚刚在维基百科上看到:

http://en.wikipedia.org/wiki/Translation_lookaside_buffer

2008年,英特尔(Nehalem)[18]和AMD(SVM)[19]都引入了标签作为TLB条目的一部分,以及在查找期间检查标签的专用硬件.即使这些没有得到充分利用,但可以设想,将来这些标签将识别每个TLB条目所属的地址空间.因此,上下文切换不会导致刷新TLB - 而只是将当前地址空间的标记更改为新任务的地址空间的标记.

以上是否确认较新的Intel CPU TLB不会在上下文切换时刷新？

这是否意味着现在在上下文切换中没有真正的开销？

(我试图理解上下文切换的性能损失)

Answer 1

正如维基百科在其上下文切换文章中所知," 上下文切换是存储和恢复进程的状态(上下文)的过程,以便可以在以后从同一点恢复执行. " 我假设在相同操作系统的两个进程之间切换上下文,而不是用户/内核模式转换(系统调用),它更快,不需要TLB刷新.

因此,OS内核需要大量时间将当前运行进程的执行状态(所有,实际上所有,寄存器和许多特殊控制结构)保存到内存,然后加载其他进程的执行状态(从内存中读入) .如果需要,TLB flush将为交换机增加一些时间,但它只是总开销的一小部分.

如果你想找到上下文切换延迟,有lmbench基准工具http://www.bitmover.com/lmbench/与LAT_CTX测试http://www.bitmover.com/lmbench/lat_ctx.8.html

我找不到nehalem的结果(phoronix套件中是否有lmbench？),但对于core2和现代Linux上下文切换可能需要5-7微秒.

对于上下文切换,还有1-3微秒的低质量测试结果http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html.无法从他的结果中获得非冲刷TLB的确切效果.

更新 - 您的问题应该是关于虚拟化,而不是关于进程上下文切换.

RWT在他们关于Nehalem "内部Nehalem:英特尔的未来处理器和系统.LTB,页表和同步"的文章中说,Nehalem将SVID添加到TLB以制作虚拟机/主机交换机(vmentry/vmexit)2008年4月2日,David Kanter ) 快点:

Nehalem的TLB条目也通过引入"虚拟处理器ID"或VPID而巧妙地改变.每个TLB条目都缓存虚拟到物理地址转换......该转换特定于给定进程和虚拟机.只要处理器在虚拟客户机和主机实例之间切换,英特尔的旧CPU就会刷新TLB,以确保进程只访问允许触摸的内存.VPID跟踪TLB中给定转换条目与哪个VM相关联,以便当VM退出并重新进入时,不必为了安全而刷新TLB.....通过降低VM转换的开销,VPID有助于提高虚拟化性能; 英特尔估计,与Merom(即65nm Core 2)相比,Nehalem往返VM转换的延迟为40%,比45nm Penryn低约三分之一.

另外,您应该知道,在您在问题中引用的片段中,"[18]"链接是"G. Neiger,A.Santoni,F.Leung,D.Rodgers和R. Uhlig."英特尔虚拟化技术:高效处理器虚拟化的硬件支持.英特尔技术期刊,10(3).",这是有效虚拟化(快速访客 - 主机交换机)的功能.

Answer 2

如果我们计算高速缓存失效(我们通常应该这样,并且它是实际上的上下文切换成本的最大贡献者),由于上下文切换导致的性能损失可能很大:

https://www.usenix.org/legacy/events/expcs07/papers/2-li.pdf(不可否认有点过时,但我能找到的最好的)使其在100K-1M CPU周期范围内.从理论上讲,对于一个多插槽服务器盒,最糟糕的情况是具有32M L3每插槽高速缓存,由64字节高速缓存行组成,完全随机访问,并且主RAM的L3/100周期的典型访问时间为40个周期,惩罚可以达到30M + CPU周期(!).

根据个人经验,我会说它通常在数十K周期的范围内,但根据具体情况,它可能会有一个数量级的差异.

Answer 3

让我们将任务转换的成本分为“直接成本”（任务转换代码本身的成本）和“间接成本”（TLB丢失的成本等）。

直接费用

对于直接成本，这主要是保存上一个任务的状态（对用户空间可见的体系结构），然后为下一个任务加载状态的成本。视情况而定，这主要是因为它可能包含FPU / MMX / SSE / AVX状态，也可能不包含，而FPU / MMX / SSE / AVX状态可能会添加多达KiB的数据（尤其是涉及AVX时-例如，AVX2本身为512字节，而AVX- 512本身超过2 KiB）。

请注意，有一种“惰性状态加载”机制，可以避免加载（部分或全部）FPU / MMX / SSE / AVX状态的成本，并避免在未加载状态时保存该状态的成本；并且出于性能原因可以禁用此功能（如果几乎所有任务都使用该状态，则“需要加载使用状态的成本”陷阱/异常超出了您在任务切换期间避免执行此操作所节省的费用）或出于安全原因（例如，因为Linux中的代码确实“保存了使用情况”而不是“保存然后清除，如果使用了”，并将属于一个任务的数据保留在寄存器中，而这些任务可以通过推测性执行攻击由其他任务获得）。

还有其他一些成本（更新统计信息-例如“先前任务使用的CPU时间量”），确定新任务是否使用与旧任务相同的虚拟地址空间（例如，同一进程中的不同线程）等。

间接费用

间接成本实质上是CPU拥有的所有“类似于缓存”的东西的有效性的损失-缓存本身，TLB，更高级别的分页结构缓存，所有分支预测的内容（分支方向，分支目标，返回缓冲区）等。

间接成本可分为3个原因。一种是间接成本，其发生是因为事物被任务开关完全冲洗掉了。过去，这主要是由于在任务切换过程中刷新了TLB导致的TLB丢失。请注意，即使使用PCID，也可能发生这种情况-限制为4096个ID（并且使用“融化缓解”时，这些ID成对使用-对于每个虚拟地址空间，一个ID用于用户空间，而另一个ID用于用户空间。对于内核），这意味着当使用的虚拟地址空间超过4096（或2048）时，内核必须回收先前使用的ID，并刷新所有TLB以重新使用该ID。但是，现在（伴随所有推测性执行安全性问题），内核可能会刷新其他内容（例如，

间接成本的另一个原因是容量限制。例如，如果L2缓存最多只能缓存256 KiB的数据，而先前的任务使用的缓存多于256 KiB的数据；那么L2高速缓存将充满对下一个任务无用的数据，并且由于“最近最少使用”，已将下一个任务要缓存（并且以前已缓存）的所有数据清除了。这适用于所有“类似缓存”的东西（包括TLB和更高级的页面结构缓存，即使使用PCID功能时也是如此）。

间接成本的另一个原因是将任务迁移到另一个CPU。这取决于哪个CPU-例如，如果将任务迁移到同一内核中的其他逻辑CPU，则两个CPU可能共享很多“类似于缓存”的内容，并且迁移成本可能相对较小；如果将任务迁移到其他物理包中的CPU，则两个CPU都不会共享“类似于缓存”的内容，并且迁移成本可能会相对较大。

请注意，间接成本幅度的上限取决于任务的作用。例如，如果任务使用大量数据，则间接成本可能相对较高（大量缓存和TLB未命中），并且如果任务使用少量数据，则间接成本可以忽略不计（非常少的缓存和TLB未命中）。

无关

请注意，PCID功能有其自己的成本（与任务切换本身无关）。特别; 当在一个CPU上修改页面翻译时，可能需要使用称为“多CPU TLB击落”的方法使其他CPU上的页面翻译无效，这相对昂贵（涉及IPI /处理器间中断，该中断会打乱其他CPU，并且成本“低数百每个CPU的周期数）。没有PCID，您可以避免其中的一些。例如，如果没有PCID，对于在一个CPU上运行的单线程进程，您知道没有其他CPU可以使用相同的虚拟地址空间，因此知道您不需要执行“多CPU TLB击倒” “，并且如果多线程进程仅限于单个NUMA域，则仅该NUMA域中的CPU才需要参与”

当然，与ID管理相关的还有一些成本（例如，确定哪些ID可自由分配给新创建的任务，在任务终止时撤销ID，在存在更多ID时使用某种“最近最少使用”的系统来重新使用ID）虚拟地址空间，而不是ID等）。

由于这些成本，在某些情况下，使用PCID的成本必然会超过“由于任务切换而导致的TLB丢失少”带来的好处（使用PCID会使性能变差）。