每年，Google都会举办Google Summer of Code活动，主要的OpenSource项目在学生中找到新的有才华的开发人员。 在2019年，我们的CRIU项目不仅成功通过了资格赛，而且还一次吸引了几位年轻的开发商。 关于为什么所有这些以及CRUI的工作如何在GSoC框架内进行-仔细阅读。
Virtuozzo的我们有一个很小但已经很受欢迎的项目，称为CRIU。 这是一个相当复杂的系统实用程序，提供了一组内核补丁（顺便说一句，大多数内核补丁已被接受到主内核树中），您可以使用它们执行诸如实时迁移容器或更新内核而无需重新启动应用程序之类的事情。
我们从2011年开始这个项目。 尽管该实用程序最初引起了很多问题，并且有人认为它无法实现，但CRIU逐渐成为了一种成熟的工具。 迄今为止，包括谷歌和IBM这样的巨头在内的数十家公司的一百五十多名贡献者已经设法参与其中。 尽管如此，寻找新成员的工作仍在继续，今年我们终于击中了Google Summer of Code（GSoC）。
GSoC是Google赞助的年度活动，旨在吸引学生参加各种开源项目。 一方面，来自开放项目的团队寻求参加活动，另一方面，希望为社区发展做出贡献并证明其在真实项目中的专业精神的学生。
要加入GSoC团队，必须提交一份申请书，其中详细说明了项目描述，学生可以从事的几个主题以及所谓的“导师”列表-该项目的积极参与者将帮助学生完成艰苦的工作。 学生必须选择一个或多个项目，并将简历发送给导师。
在学年中旬，Google会考虑团队的申请并选择要参与的项目，并在暑假临近时，团队选择他们准备工作的学生，然后Google进行最终过滤并根据团队分配学生。 在夏季，工作开始，历时三个月。 学生每30天提交一次中期报告，他们的导师会评估结果并为继续（或终止）工作提出建议。
内存优化和二进制日志的实现
我承认，2019年并不是我们首次尝试进入GSoC。 到目前为止，我们还无法完成从Google选择项目的过程。 但是我们没有放弃（总的来说，提交申请并不难），最后一切都完成了-Google意识到我们项目的开发非常重要，并在GSoC上发布了CRUI。
我们为学生准备了许多主题，其中一个主题更美丽，更复杂。 一个令人惊喜的事实是，社区中的每个人都有表演者。 有些人知道所提出的问题，并愿意担任导师。 在学生备案阶段，我们收到了一次完整的“竞争”-每个主题都有2名学生申请，并且几乎所有学生都有出色的输入数据。 最终的选择使我们能够从正在进行的过程中以及从二进制日志的实现中选出两名学习内存保存代码优化主题的学生。
由于CRIU是实时应用程序迁移的系统，因此当与进程本身并行地读取和写入进程使用的内存并将其写入映像文件时，它将具有这种操作模式。 我们称其为该过程的“活心手术”，因为它持续不断地工作而不停止。 在GSoC回合之前，使用vmsplice系统调用将所有内存放入管道中，这一次产生了噪音，然后继续执行该过程，然后CRIU将该内存缓慢转储到文件中（如果是实时迁移，则将其转储到网络通道中）。 原则上，这是一种可行的方法，但是问题是位于管道中的内存被有效锁定（mlock），并且内核在必要时无法将其卸载到磁盘（交换）。
从体系结构的角度来看，我们希望通过调用process_vm_readv替换管道以小部分复制内存。 这项创新不久前就出现在Linux内核中（顺便说一下，此调用有一个叫做process_vm_writev的双胞胎兄弟）。 但是同时，它还允许您极大地简化和加快strace实用程序和调试器的工作，这些工作可以在处理某些其他任务的进程的内存中查找。
由于使用进程内存的代码是实用程序中的核心代码之一，因此优化工作变得很复杂。因此，它必须绝对可靠。 保存页面中的任何错误都可能导致该进程接收到其内部对象的不一致状态（CRIU当然不会对此“知道”任何信息），并且在恢复后，如果没有任何明确的诊断信息，该进程将掉线。
此开发的第二个困难是几乎所有CRIU功能都涉及使用内存。 这些是通常的检查点还原过程，它们是其各种优化的版本，例如预转储或延迟还原。 在下一个报告周中，甚至有一次我们计划从项目中“解雇”学生，但是幸运的是，我们没有这样做，现在我们在devel分支中等待已久的优化。
GSoC 2019框架中的第二个任务是开发和实施所谓的二进制日志。 事情是这样的：当CRIU工作时，该实用程序将有关其工作的消息写到文件（或屏幕，但更好的是写到文件）。 这些职位的重要性是巨大的！ 如果由于某种原因备份或还原过程未成功完成，那么理解该原因的唯一方法是尽可能详细地分析每个步骤，因此您需要有关实用程序操作的信息。 理想情况下，程序需要最详细的日志和图像文件（如果有）。 实际上，这种要求很难满足。
为了获得最详细的日志，CRIU提供了一种适当的模式，并且绝大多数用户（甚至可能是所有用户）总是将其激活。 但是，criu在此过程中生成的信息量是如此之大，以至于日志记录本身开始明显影响系统的速度。 一项小型研究表明，我们将90％的时间用于记录输出格式操作-即，在“相同”％d，％08s，％。2f和printf系列函数的其他修饰符上。 关闭日志可以将进程的保存和还原时间从10％减少到30％，具体取决于进程本身的大小。
为了关闭使用如此大量的系统资源进行日志记录，但又希望使日志尽可能多地提供信息，我们决定放弃格式化并将二进制数据保存到日志文件中。 毕竟，如有必要，您可以稍后格式化它们。 第二名学生完成了这项任务，其补丁也已被开发部门接受。
不仅在GSoC
顺便说一句，参加GSoC的另一个有趣的事实是，有第三位学生来到我们这里，他们希望解决匿名问题。 毕竟，由于图像文件包含用户可能不希望与任何人共享的秘密信息，因此通常无法获得图像文件-内存的内容，处理的文件，网络连接中的队列的内容等等。 为了解决此问题，我们在应用程序中提交了一项名为“图像匿名化”的功能，但Google不接受。
不过，该主题并未失去其相关性，最终想要在GSoC框架内进行处理的学生最终决定在Google事件之外独立研究该问题。
结论
当然，参与GSoC是一次积极的经历。 我们非常喜欢和珍视的CRIU工具收到了一些更强大的发展动力，它变得更加成熟和方便。 因此，它可能对谁有用，请愉快地使用它！
另一方面，我们坚信参与此类事件的问题是对我们项目的恒心和信心。 如果您需要开发人员，那就不要厌倦提交申请和制定有趣的新主题。 您可能会发现完全来自另一个国家或什至另一个公司的出乎意料的贡献。