4

由于系统调用仿真更容易设置,我想知道在运行用户态程序时使用完整系统仿真有什么好处。

或者换句话说,在整个系统中建模了哪些有趣的方面,而不是系统调用仿真模式,它们什么时候很重要?

在文档中提到:http ://gem5.org/Splash_benchmarks完整系统是

现实的:你得到了实际的 Linux 线程调度器来调度你的线程

这是唯一的优势,还是对优化应用程序或研究微架构的用户有其他优势?

我还怀疑 MMU 仿真是另一个重要特性,它只能在完整系统模式下正确建模,并且可能会影响程序性能。

4

2 回答 2

3

SE的优势:

SE的缺点:

所以我的建议是:

  • 先试试 SE。如果它有效,那就太好了。如果没有,请尝试快速修复它,因为大多数问题都是微不足道的。拥有 SE 设置将在整个系统上为您节省大量时间,而且它通常具有足够的代表性。

  • 否则,使用 FS 模式。它只是设置更简单,更具代表性,而且对大多数人来说,性能损失是可以接受的。

    您也可以先使用 SE,然后转到 FS 以进一步验证您最重要的 SE 结果,因为 FS 速度较慢,因此您可以验证较少不同的设置。

于 2018-06-21T07:38:53.030 回答
3

应该首选完整系统模式(如果可以使用它)。使用它有很多好处,主要是模拟的保真度,这是系统调用模拟模式无法实现的。(内核与应用程序的交互可能很重要,这取决于研究人员试图进行的研究。)此外,用户无需担心实现(或调试)系统调用实现。

话虽如此,系统调用仿真模式在适当的条件下可能很有用。运行应用程序代码更快,因为后台没有运行内核。如果您想完全减轻它,也没有系统噪音。可以说,引导新设备模型也更容易。您可以在没有驱动程序支持的情况下处理模型,并通过假接口使魔术发生。(它使您不必完美地建模裸机接口或不必编写自己的设备驱动程序。)

您对动态链接和多线程支持的评论是相关的。如果动态链接是固定的,您应该能够使用系统的 pthreads 库,并且可以完全忘记与 m5threads 的链接。pthread 库支持在模拟器中已经存在了一段时间(它正常工作所必需的系统调用)。

但是,线程实现有一个警告。您需要在模拟开始时预先分配足够的线程上下文(通过调用 se.py 脚本上的 -n 选项)。

详细地说,没有在后台运行的操作系统来调度处理器上的线程。(我在这里非常松散地使用术语线程和处理器。)为了避免调度问题,您必须预先分配足够的处理器,以便可以在调用 clone/execve 时创建线程。有一个限制,你不能拥有比处理器更多的线程(与操作系统可以随意调度它们的真实系统不同)。

配置脚本的行为可能与研究人员希望它们针对多线程工作负载的行为不同。研究人员需要验证缓存配置是否正确,以及它们是否像真机一样共享某些缓存级别。如果应用程序多次调用 clone/execve,则可能无法使生成的配置表现得真实。

您关于建模加速器的最后陈述是不正确的。AMD GFX8 模型确实使用系统调用仿真模式。(此外,我们开发了一个从未公开发布的 NIC 模型。)它涉及创建一个假驱动程序并通过与真正驱动程序相同的 ioctl 接口对其进行操作。Linux 将所有内容都视为文件,因此驱动程序通过开放的系统调用接口打开,您可以在那里捕获它。您可能还需要做其他事情(例如在配置中映射 mmio 范围),但驱动程序接口是主要部分。应用程序与驱动程序交互,驱动程序与加速器模型交互。

于 2019-05-30T02:44:53.113 回答