问什么时候与gem5中的用户程序一起使用完整系统FS与syscall仿真SE？

EN

SE的优势：

• 有时更容易设置基准测试， all syscalls you need are implemented (see also，see also)，如果您有just the right cross compiler，当然没有人正确地记录了哪个是just the right cross compiler。
• SE运行Dhrystone，大约2倍的https://github.com/cirosantilli/linux-kernel-module-cheat/tree/00d282d912173b72c63c0a2cc893a97d45498da5#user-mode-vs-full-system-benchmark，基准测试不产生任何系统(除了实际基准运行之前/之后的信息)。
• 由于内核不是并行运行的，因此更容易获得更大的可见性和对应用程序所做工作的控制。例如，统计数据只适用于应用程序，GDB仅用于应用程序：thread-aware gdb for the Linux kernel

SE的缺点：

• 实际上，很难设置基准，因为它太脆弱/有太多的限制。 如果您的内容不能立即显示出来，那么只创建或下载完整的系统映像就更容易了，这样就更可靠了。 如果您仍然感兴趣，下面是一个最小的工作Ubuntu设置示例：How to compile and run an executable in gem5 syscall emulation mode with se.py?
• 代表性较低，因为没有实际操作系统正在运行。
• 截至2018年6月，ARM没有动态链接：How to run a dynamically linked executable syscall emulation mode se.py in gem5?
• 如果您想像GPU那样评估加速器，您必须为它创建一些稍微定制的接口，因为在内核上面没有像往常一样运行的内核驱动程序。 布兰登在他的回答中指出，这实际上是以前做过的：https://stackoverflow.com/a/56371006/9160762。

所以我的建议是：

• 先试试SE。如果成功的话，很好。如果没有，请尽快修复它，因为大多数问题都是微不足道的。拥有SE设置将为您在整个系统上节省大量时间，而且它通常具有足够的代表性。
• 否则，使用FS模式。它只是更简单的设置，更有代表性的，和性能命中是可以接受的大多数。 您还可以首先使用SE，然后转到FS来进一步验证最重要的SE结果，因为FS比较慢，因此可以验证更少的不同设置。

最好采用完整的系统模式(当可能使用时)。使用它是有好处的，主要是在仿真中保真度，这在系统调用仿真模式下是不可能的。(根据研究人员正在进行的研究，与应用程序的内核交互可能很重要。)此外，用户不需要担心实现(或调试)系统调用实现。

尽管如此，在适当的条件下，系统调用仿真模式可能是有用的。运行应用程序代码更快，因为后台没有运行内核。如果您想要完全减轻系统噪音，也没有系统噪音。可以说，引导一个新的设备模型也更容易。您可以在没有驱动程序支持的情况下对模型进行处理，并通过假接口实现魔术。(这就省去了你必须完美地模拟裸金属界面，或者编写你自己的设备驱动程序。)

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

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

详细说明，在后台没有运行操作系统来调度处理器上的线程。(我在这里非常宽松地使用线程和处理器这个术语。)为了避免调度问题，您必须预先分配足够的处理器，以便能够在调用克隆/执行时创建线程。有一个限制，就是您永远不能拥有比处理器更多的线程(不像真正的系统那样，操作系统可以随意安排线程)。

配置脚本可能不会表现出研究者希望它们对多线程工作负载的行为。研究人员需要验证缓存配置是否正确，并且它们是否共享某些缓存级别，就像真正的机器所做的那样。如果应用程序多次调用克隆/execve，则可能无法使生成的配置实际运行。

你上次关于加速器建模的说法是不正确的。AMD GFX8模型确实使用了系统调用仿真模式。(此外，我们开发了NIC模型，但从未公开发布。)它涉及创建一个假驱动程序，并通过与实际驱动程序相同的ioctl接口对其进行操作。Linux将一切都当作文件对待，因此驱动程序是通过开放的系统调用接口打开的，您可以在那里捕获它。您可能还需要做其他一些事情(比如配置中的map mmio范围)，但是驱动程序接口是主要的部分。应用程序与驱动程序交互，驱动程序与加速器模型交互。