x86_64中的中断成本为多少？
x86_64中的中断成本为多少？例如由于页面错误导致的中断？内核需要多少周期来服务中断，然后回到用户空间？我有兴趣只知道由于中断造成的成本，并将中断的用户级线程调度回来，所以我们可以忽略中断处理程序内部发生的事情。x86_64中的中断成本为多少？
这是一个复杂的问题，无法轻松回答。
您必须保存中断中使用的所有（已用）寄存器（标量，sse，fpu状态，avx等）。
也许你必须更改虚拟地址空间上下文。
当你完成后，你必须重置保存的上下文。
而所有的缓存/ RAM加载效果都会改变所需的循环次数。
（注：中断不应该被换出，但不知道如果Linux支持这一点，或者如果它是在所有可能的）
内核通常禁止使用除整数指令之外的任何内容。而且，它们通常也是（Linux和Win，至少）映射到进程的地址空间，只能被访问保护。 – zvrba 2012-04-23 15:21:25
@zvrba：虽然内核通常不使用浮点等，但您仍然需要保存状态，通常懒惰保存（即，如果进程未使用FPU，请不要保存它），因为您可以切换到另一个也使用FPU/SSE /其他进程... – ninjalj 2012-04-23 18:04:33
@zvrba你说得对，中断处理程序不需要保存所有寄存器，但可能例如SSE由于memcpy。你说得对，在windows下它们已经被映射到进程地址空间，但我不知道Linux中是否出现这种情况。关键还是，你必须抢救一些登记册。你必须在内存中映射某些东西，但这些不应该是“重量级”的东西，由于缓存效应，这通常很难量化。 – Christopher 2012-04-24 08:11:07
对于odrinary中断（硬件IRQ或类似被零除普通的例外），这是可能有可能给出一个上限。
即使不涉及磁盘IO，也要评估处理页面错误的时间，因为CPU必须遍历页表，这会引入许多变量，因此评估时间尤其棘手。页面错误的发生不仅仅是因为页面不存在，而且还因为访问冲突（例如，试图写入只读页面）。在任何情况下，如果TLB中尚未存在页面映射（缺少映射从不缓存），那么即使调用页面错误处理程序，CPU也必须首先遍历多级页表。访问页表项（如果地址尚未缓存在TLB中）的时间又取决于某些项是否已经在数据缓存中。
所以从访问的线性地址到PF处理程序中的时间被调用可能是从大约200个循环的任何（最好的情况下; TLB条目目前，例外由于错误的接入类型 - 只是环切换）至〜2000次循环（没有存在TLB条目，数据高速缓存中没有页表项）。这只是执行1）执行错误的用户模式指令和2）执行页错误处理程序的第一条指令之间的时间。
[旁注：因为我不知道是否有可能建立使用分页的硬实时系统。]
这将取决于硬件。因此，我不确定为什么要对GCC，C或Linux进行标记。 – 2012-04-23 14:07:37
嗯...这不可能涉及从交换内存中分页，即几十毫秒？如果是这样，我不明白这部分可以被忽略，因为让用户空间代码在存储内容到位之前进行似乎是不可能的。 – unwind 2012-04-23 14:22:47
你正确的放松，但在这一刻我想知道开销只是由于用户空间中断线程的中断和调度返回。假设所有页面都在RAM中。 – pythonic 2012-04-23 14:31:21