最初我认为上下文切换的开销是TLB被刷新，但我在维基百科上看到:
http://en.wikipedia.org/wiki/Translation_lookaside_buffer
2008年，英特尔(Nehalem)[18]和AMD(SVM)[19]都引入了标记作为TLB条目的一部分，并专门设计了硬件来检查查找期间的标记。尽管这些标记没有得到充分利用，但预计在未来，这些标记将标识每个TLB条目所属的地址空间。因此，上下文切换不会导致TLB被刷新 - 只需将当前地址空间的标记更改为新任务的地址空间的标记。
上述内容是否证实了对于更新的英特尔CPU，在上下文切换时TLB不会被刷新？
这是否意味着现在在上下文切换中没有真正的开销了？
（我试图理解上下文切换的性能惩罚）
正如维基百科在其上下文切换文章中所述，"上下文切换是存储和恢复进程状态（上下文）的过程，以便稍后可以从同一点恢复执行。"。我假设上下文切换发生在同一操作系统内的两个进程之间，而不是用户/内核模式转换（系统调用），后者速度更快且不需要TLB清除。
因此，操作系统内核需要大量时间将当前正在运行的进程的执行状态（真正的所有寄存器和许多特殊控制结构）保存到内存中，然后加载其他进程的执行状态（从内存中读取）。如果需要TLB清除，它会增加一些开销，但这只是总体开销的一小部分。
如果您想找到上下文切换延迟，可以使用lmbench基准测试工具http://www.bitmover.com/lmbench/进行LAT_CTX测试http://www.bitmover.com/lmbench/lat_ctx.8.html
让我们将任务切换的成本分为“直接成本”（任务切换代码本身的成本）和“间接成本”（TLB缺失等的成本）。
直接成本
对于直接成本，这主要是保存前一个任务的（面向用户空间的可见架构）状态的成本，然后加载下一个任务的状态。这取决于具体情况，主要是因为它可能包括FPU / MMX / SSE / AVX状态，这些状态可以增加几KB的数据（特别是如果涉及AVX-例如，AVX2本身就是512字节，而AVX-512本身就超过了2 KB）。
请注意，有一种“延迟状态加载”机制，以避免加载（某些或全部）FPU / MMX / SSE / AVX状态的成本，并避免保存未加载的状态；出于性能原因（如果几乎所有任务都使用该状态，则“正在使用该状态需要加载”陷阱/异常的成本超过了尝试在任务切换期间避免执行该操作所节省的成本）或出于安全原因（例如，因为Linux中的代码执行“保存使用的内容”，而不是“保存然后清除使用的内容”，并将属于一个任务的数据留在可以通过漏洞利用攻击获得的寄存器中）。
还有一些其他的成本（更新统计信息 - 如“前一个任务使用的CPU时间量”），确定新任务是否与旧任务使用相同的虚拟地址空间（例如同一进程中的不同线程）等。
间接成本
间接成本实际上是 CPU 所具有的所有“类似缓存”的东西损失的效率，包括缓存本身、TLB、更高级别的分页结构缓存、所有分支预测相关的东西（分支方向、分支目标、返回缓冲区）等等。
间接成本可以分为三种原因。其中一种是由于任务切换完全刷新而发生的间接成本。过去，这主要限于因任务切换期间TLBs被刷新而导致的TLB未命中。请注意，即使使用PCID，也可能会发生这种情况 - ID的数量有4096个限制（当使用“熔断缓解”时，ID成对使用 - 对于每个虚拟地址空间，一个用于用户空间，另一个用于内核），这意味着当使用超过4096（或2048）个虚拟地址空间时，内核必须回收先前使用的ID并刷新所有TLB以便重新使用ID。然而，现在（由于所有的漏洞问题），内核可能会刷新其他内容（例如分支预测内容），以便信息无法从一个任务泄漏到另一个任务，但我真的不知道Linux是否支持这种“类似缓存的”内容（我怀疑他们主要试图防止数据从内核泄漏到用户空间，并出于偶然而防止数据从一个任务泄漏到另一个任务）。
间接成本的另一个原因是容量限制。例如，如果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，您可以避免其中一些。例如，对于正在单个CPU上运行的单线程进程，如果没有PCID，则知道没有其他CPU可以使用相同的虚拟地址空间，因此知道不需要进行“多CPU TLB清除”，如果多线程进程限制在单个NUMA域中，则只需涉及该NUMA域内的CPU即可进行“多CPU TLB清除”。当使用PCID时，您无法依赖这些技巧，并且存在更高的开销，因为“多CPU TLB清除”并不经常避免。如果考虑缓存失效（通常应该这样做，因为它是真实世界中上下文切换成本的最大贡献者），由于上下文切换而产生的性能惩罚可能非常巨大：
https://www.usenix.org/legacy/events/expcs07/papers/2-li.pdf（尽管有点过时，但这是我找到的最好的资料）将其范围定在100K-1M CPU周期之间。从理论上讲，在32M L3每个插槽缓存由64字节缓存行组成、完全随机访问以及L3/主RAM的典型访问时间分别为40 cycles / 100 cycles的多插槽服务器盒子的最坏情况下，惩罚可以达到30M+ CPU周期！
根据个人经验，我会说它通常在几万个周期之间，但是根据具体情况，它可能相差一个数量级。
2560个线程应该只占用大约2%的CPU，但实际上在我的Core i7-4790K 4核心+ 4超线程核心台式机上，在2300个线程处CPU占用率达到了100%。
static void Main(string[] args)
{
ThreadTestClass ThreadClass;
bool Wait;
int Counter;
Wait = true;
Counter = 0;
while (Wait)
{
if (Console.KeyAvailable)
{
ConsoleKey Key = Console.ReadKey().Key;
switch (Key)
{
case ConsoleKey.UpArrow:
ThreadClass = new ThreadTestClass();
break;
case ConsoleKey.DownArrow:
SignalExitThread();
break;
case ConsoleKey.PageUp:
SleepTime += 1;
break;
case ConsoleKey.PageDown:
SleepTime -= 1;
break;
case ConsoleKey.Insert:
for (int I = 0; I < 64; I++)
{
ThreadClass = new ThreadTestClass();
}
break;
case ConsoleKey.Delete:
for (int I = 0; I < 64; I++)
{
SignalExitThread();
}
break;
case ConsoleKey.Q:
Wait = false;
break;
case ConsoleKey.Spacebar:
Wait = false;
break;
case ConsoleKey.Enter:
Wait = false;
break;
}
}
Counter += 1;
if (Counter >= 10)
{
Counter = 0;
Console.WriteLine(string.Concat(@"Thread Count: ", NumThreadsActive.ToString(), @" - SleepTime: ", SleepTime.ToString(), @" - Counter: ", UnSafeCounter.ToString()));
}
System.Threading.Thread.Sleep(100);
}
IsActive = false;
}
public static object SyncRoot = new object();
public static bool IsActive = true;
public static int SleepTime = 1;
public static long UnSafeCounter = 0;
private static int m_NumThreadsActive;
public static int NumThreadsActive
{
get
{
lock(SyncRoot)
{
return m_NumThreadsActive;
}
}
}
private static void NumThreadsActive_Inc()
{
lock (SyncRoot)
{
m_NumThreadsActive += 1;
}
}
private static void NumThreadsActive_Dec()
{
lock (SyncRoot)
{
m_NumThreadsActive -= 1;
}
}
private static int ThreadsToExit = 0;
private static bool ThreadExitFlag = false;
public static void SignalExitThread()
{
lock(SyncRoot)
{
ThreadsToExit += 1;
ThreadExitFlag = (ThreadsToExit > 0);
}
}
private static bool ExitThread()
{
if (ThreadExitFlag)
{
lock (SyncRoot)
{
ThreadsToExit -= 1;
ThreadExitFlag = (ThreadsToExit > 0);
return (ThreadsToExit >= 0);
}
}
return false;
}
public class ThreadTestClass
{
public ThreadTestClass()
{
System.Threading.Thread RunThread;
RunThread = new System.Threading.Thread(new System.Threading.ThreadStart(ThreadRunMethod));
RunThread.Start();
}
public void ThreadRunMethod()
{
long Counter1;
long Counter2;
long Counter3;
Counter1 = 0;
NumThreadsActive_Inc();
try
{
while (IsActive && (!ExitThread()))
{
UnSafeCounter += 1;
System.Threading.Thread.Sleep(SleepTime);
Counter1 += 1;
Counter2 = UnSafeCounter;
Counter3 = Counter1 + Counter2;
}
}
finally
{
NumThreadsActive_Dec();
}
}
}