上下文切换的开销是多less?

本来我认为上下文切换的开销是TLB被刷新。 不过,我刚刚在维基百科上看到:

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

2008年,Intel(Nehalem)[18]和AMD(SVM)[19]都将标签作为TLB条目的一部分,并在查找期间检查标签。 尽pipe这些标签没有被充分利用,但是可以预见,将来这些标签将识别每个TLB条目所属的地址空间。 因此,上下文切换不会导致TLB的刷新 – 而只是将当前地址空间的标记更改为新任务的地址空间的标记。

上述情况是否确认新的Intel CPU不会在上下文切换时刷新TLB?

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

(我想了解上下文切换的性能损失)

Solutions Collecting From Web of "上下文切换的开销是多less?"

正如wikipedia 在其上下文切换文章中所知道的那样 ,“ 上下文切换是存储和恢复进程的状态(上下文)的过程,以便稍后可以从同一点恢复执行。 ” 我假定在同一个OS的两个进程之间进行上下文切换,而不是用户/内核模式转换(syscall),这个过程要快得多,不需要任何TLB刷新。

因此,OS内核需要很多时间来将当前正在运行的进程的执行状态(全部是真正的注册,以及许多特殊的控制结构)保存到内存中,然后加载其他进程的执行状态(从内存中读入) 。 如果需要,TLB刷新会为交换机增加一些时间,但这只是总开销的一小部分。

如果你想找到上下文切换的延迟,有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微秒。 不能从他的结果中获得不冲刷TLB的确切效果。

更新 – 你的问题应该是关于虚拟化,而不是关于进程上下文切换。

RWT在他们关于Nehalem “Inside Nehalem:Intel的未来处理器和系统,TLB,页面表和同步” 的文章中说, Nehalem在2008年4月2日由David Kanter在TLB中添加VPID来创建虚拟机/主机交换机(vmentry / vmexit ) 更快:

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

此外,您应该知道,在您提到的问题中,“[18]”链接是“G. Neiger,A. Santoni,F. Leung,D. Rodgers和R. Uhlig。Intel Virtualization技术: 对高效处理器虚拟化的硬件支持,英特尔技术杂志,10(3)。“,所以这是有效虚拟化(快速客户 – 主机交换机)的特征。

如果我们计算缓存失效(我们通常应该这样做,哪一个是最大的贡献者来在现实世界中切换成本),由于上下文切换而导致的性能损失可能是巨大的:

http://www.cs.rochester.edu/u/cli/research/switch.pdf (虽然有些过时了,但是我能找到的最好的)在100K-1M的CPU时钟范围内。 从理论上讲,32M三级高速缓存由64字节高速缓存线组成,完全随机存取,对于主RAM,L3 / 100时钟的典型存取时间为40个时钟,惩罚可高达30M + CPU时钟(!)。