硬件调度器辅助服务干了些什么？

    我弄了很久的硬件调度器辅助服务大家都很感兴趣，也可能想知道这个服务做了些什么来帮助windows进行大小核调度，我这里就解释一下里头的原理，同时展示一下效果。我们知道Intel thread director会根据指令执行的特征向windows提供对线程的调度建议，然后系统采用建议。但是呢，intel和微软默认定下了前后台调度策略，就导致在出现前后台情景时系统会忽略从调度器来的建议，就导致了调度错误的问题。实际上这并不是一个什么大不了的问题，我们可以手动关闭这个机制，让系统始终采纳调度器的建议。

    但是呢，调度器并不总是很智能，根据技术文档，这个硬件调度器竟然是“猜测”不同线程类型会在大核与小核上的ipc的不同，而且这个猜测是以固件的形式固定在微码中的，所以在大多数情况下，调度器只会给出“请调度给大核”的建议，如果完全按照调度器的建议调度线程，那么只有class3这个类型的线程，也就是busy waiting的线程会主动去使用小核，其实这就是当我们完全disable系统的core parking功能后发现的小核上面往往只有一个核心有一丁点负载的原因，除非大核满了后才会被动使用小核。此外，系统可以对大小核分别设定epp值，这就是我之前的版本做的事情，用户可以分别设定这两个epp的值，然后调度器就会按照固定的策略对线程进行调度。但是系统的设定很固定，开机后就不变了，所以线程调度也就固定下来了。

    后来我改进了调度服务，开始引入更多的机制，把调度器底层的关于指令执行的信息与系统关于线程负载的信息结合到一起，就成为了现在X版本的逻辑核心。具体而言，现在的X版本可以：1. 逐核心逐线程的识别最佳核心，找到在检测期内（一般设定为10ms）实时ipc最高的那个大核（不使用超线程的那个大核）动态提升频率，这样可以在不动其他大核的前提下实现高单线程性能的同时还能减少发热；2. 识别大小核的指令负载的比重变化。以10ms的精度对大小核簇的指令负载进行比较，并动态地调整大小核的功耗分配，这样可以针对主要负载进行加速，提高能效的同时提高整体性能；3. 识别活动线程数，并根据活动线程区分偏单线程的任务和偏多线程的任务，并且在多线程负载条件下更加主动的使用小核来承担多线程任务；4. 在使用超线程的时候会实时比较超线程与小核之间的负载和性能水平，在超线程负载较低或者其上的线程不重要时主动降低其功耗，节省的功耗就能加在单线程大核以及多线程小核上，此时超线程大核可以看作两个比小核还要小的微核。5. 总是确保在有单线程大核时优先确保其单线程性能，这个在当前的系统中默认是做不到的，因为windows会在有大量负载时倾向于将功耗平均分配给大核，导致大家的频率都不高。

    下面我选择了几个有代表性的游戏，用throttlestop来展示运行不同游戏时，调度服务如何根据不同游戏的负载有针对性的进行优化的过程，尤其注意各个核心的频率和负载有什么不同。游戏将从单线程向多线程过渡，关注其变化。

    1. 偏单线程

房车赛

注意到大部分的负载都集中core3和core4上，因此其他核心的功率也向这两个大核倾斜。

这个是4个重负载，其他的中等负载在小核上，因此小核有较高的频率来应对多线程任务

2. 中等线程

控制control

3. 超多线程

失落大陆，一个比较冷门的游戏，这里最能体现调度服务的特点，可以看到在触发温控下没有使用超线程的大核核心仍然可以维持在很高的频率，而使用超线程的大核与小核频率都降下来把功耗转移给物理大核，这样我们就有了很高的单线程性能的同时也利用超线程和小核大量扩展了多线程性能。而且这个游戏有个bug，它的重负载不会放到favored core也就是core3 和core4上，调度服务很好地识别到这一点并准确的加速了core1和core2，可以看到轻松吃满了gpu。

古墓丽影

这个游戏吃线程数吃的厉害，可以看到所有大核心的超线程都被使用了，调度服务识别到这一点，将所有功耗都倾斜给超线程，因为在没有物理大核在场的情景下超线程有几率实现更高的单线程性能，所以把小核功耗与负载都转移给超线程是更加合理的决定。

总之，现在X版本还在不断迭代中，主要是继续优化各种阈值条件参数，继续消除一些可能的bug。感谢大家的支持！