c - 如何在Windows(或Windows)等操作系统上测量时间片的长度？

Question

有什么方法可以获取时间幻灯片的长度？如何设计实验以某种方式弄清楚它，例如一段C代码

尽管我已经详细阅读了名为How to know Linux scheduler time slice?的相关问题，但是对于如何设计C代码以获取Win 10的时间片，尚无任何答案。

Answer 1

对此存在一个艰巨的挑战，因为根据定义，计时器中断是异步的，内核可以决定是否在任何计时器中断上抢占您的进程。

可能您可以访问（当然，如果您计划一个如此棘手的问题，我假设您具有管理员权限）一个内核变量，注册它执行的上下文切换次数，然后计算从自过去一段时间以来的CPU。

正确的是，您将在第一次启动计时表时，然后在您尝试查看发生了什么时进行安排。

试图知道您的进程被程序点之间的某个程序中断了多少次是一项艰巨的任务，因为有许多设备正在执行此操作，并且通常您不能假定在这些中断中的任何一个处都有上下文切换。通常，内核维护计数器以知道已经计数了X个类型的中断，并且您可以使用计数器值的差来知道此后发生了X个类型的中断。通常不知道哪些代码，或者如何将它们更改为进程（或线程）上下文切换，而是查看内核源代码。

但是...。您有一种简单的方法来检查估算。如果通过使用系统中可用的不同clock_gettime时钟比较时间，则可以估计您的进程代表其消耗的cpu时间，以及系统在此之前花费了多少时间。从时钟之间的差异中，您将获得一个粗略且不精确的值。例如。 FreeBSD有


CLOCK_VIRTUAL仅当CPU代表调用进程在用户模式下运行时才递增。
CLOCK_PROF当CPU在用户或内核模式下运行时增加。
CLOCK_PROCESS_CPUTIME_ID返回调用过程的执行时间。
CLOCK_THREAD_CPUTIME_ID返回调用线程的执行时间。
CLOCK_REALTIME_PRECISE作为挂钟应增加。


因此，您有许多时钟可供选择。在linux中，时钟的数量减少了，但是无论如何，您大多数时候都可以对此有所了解。

注意

根据评论，您可以：


  @ЯрославМашко非常感谢！我已经尝试过了，它的答案是15毫秒，但是有什么办法可以通过创建到完整CPU的进程来观察时间片的切换来解决它？


您不能在用户进程中执行此操作，因为显而易见的原因，它将由内核调度，以允许其他进程执行，然后您根本无法进行任何测量。这种意义上的任何事情，都将需要触摸大量内核代码，并使您的系统效率非常低下，因为它需要花费时间在每个上下文切换处收集所有信息。但是您拥有完整的内核源代码，也许您可​​以研究这种方法。普通工具（例如top(1)或htop(1)）会访问内核变量以获取内核更新的计数器，并获得内核正在执行的操作的平均值...这是因为记录了所有内核活动要由一个日志记录进程是一种递归情况，在这种情况下，还必须考虑到您执行的所有过程，并且您将陷入无限递归循环，在此循环中，系统负载会受到更严重的破坏，从而导致您想要更精细的结果。

有些处理器（最有可能是基于ARM的处理器）具有调试模块，这些模块允许它们吐出专用的线，并在全油门运行时执行所有活动。但是，它们通常提供的信息量必须由功能更强大的系统处理，该系统能够消化这些cpus发出的大量信息。无论如何，由于信息永远不会在调试的系统中使用，因此这并不表示存在问题（递归性打破了循环）

顺便说一句，检查您发表的另一条评论是否有15毫秒，这似乎很奇怪。您需要在15ms内重新安排时间，但是要进行该测量，您必须再进行两次系统调用（总共三次，两次系统调用以请求时钟时间，而一次睡眠最少时间），这与内核通常没有任何意义。允许进程正常运行更长的时间（如果必须这样做）。进行上下文切换意味着切换其所有虚拟地址空间，这意味着使大量内存缓存信息无效，并使CPU速度大大降低，因此通常情况下，内核会在需要时给进程片提供更多的支持。如果您能够在如此短的时间内再次切换回您，则可能是因为您的进程是唯一有资格运行的进程，在这种情况下，最可能的事情是内核在此期间没有安排任何时间。内核最多允许一个进程运行，因此系统不会被一个耗时的CPU锁定。但是正常的是，没有进程会完全消耗其时隙...因此，要进行这种测试，您需要在完全cpu上运行多个进程，以查看内核如何为每个cpu分配cpu。

在普通的64位intel cpu中，FreeBSD上的内核以1000ticks /秒的速度运行，这意味着，通常情况下，如果内核将cpu切换到一个或另一个进程，则内核以1 / 1000sec的间隔进行决策。但是很多时候它决定不切换进程，而是继续运行CPU内进程。在linux中，您可以使其不跳动，这意味着计时器不会以固定的速率中断CPU，而只是在某些东西使计时器唤醒时才中断。