Answers:
kswapd0占用任何CPU且您没有交换空间，则系统几乎快用完了RAM，并试图（实际上）通过交换可执行文件中的页面来处理这种情况。正确的解决方法是减少工作量，添加交换或（最好）安装更多RAM。添加交换将提高性能，因为内核将提供有关交换到磁盘内容的更多选项。如果没有交换，内核实际上被迫交换应用程序代码。
kswapd0正在使用某些CPU，而又不想这样做，请降低swappiness设置。但是，除非您的交换由遭受写入问题的SSD支持（例如，损耗均衡算法不良），否则降低会swappiness降低系统的整体性能。这样做的想法是在需要更多RAM的情况下在交换中保留RAM 的副本 -在这种情况下，RAM中的副本将立即被丢弃，而不是在可以使用RAM之前开始交换掉。仅在系统足够空闲时才进行这种乐观交换，因此它永远不会降低系统的速度。
交换空间仅用于没有任何其他文件支持的数据。即使您没有交换设备，从磁盘上其他文件（例如可执行程序）映射的数据仍会交换为它们各自的文件。
一个众所周知的问题是，当Linux内存不足时，它会进入交换循环，而不是执行应做的事情，从而杀死进程以释放ram。只有在交换和内存已满的情况下，有一个OOM（内存不足）杀手可以执行此操作。
但是，这实际上不是问题。如果有很多令人讨厌的进程（例如Firefox和Chrome），每个进程都有使用和获取内存的选项卡，则这些进程将导致交换回读。然后，Linux进入循环，在该循环中，相同的内存在内存和硬盘驱动器之间来回移动。反过来，这会导致优先级倒置，其中来回交换一些进程会使系统无响应。
如果禁用交换，则由于kswapd0现在没有其他选择，只能交换映射的内存（例如可执行文件），这会使问题变得更糟。如果换出了可执行文件，则很有可能很快将它们再次换回。
我尝试在NetBSD中触发此行为进行测试，结果是当操作系统本身响应速度很快时，令人讨厌的进程变得异常缓慢。这意味着确实发生了交换问题，但是没有优先级倒置。但是NetBSD没有AMDGPU驱动程序，因此我暂时坚持使用Linux。也许NetBSD不会存储映射可执行文件，这就是为什么它不会进入交换循环，但是我对它的实现并不真正了解，因此不能说它没有反应。
Facebook也有这个问题，并创建了OOMD，它是Out Of Memory守护进程。这是检测kswapd0活动并开始杀死进程的守护程序。根据Facebook的说法，这几乎完全消除了Linux服务器无响应的问题。但是，我尚未对其进行测试，也不知道它在其他服务器或台式机/笔记本电脑上的运行情况。有吸引力的是，OOMD拥有一些逻辑来决定首先终止哪些进程，以保留系统进程以及其服务器系统中负责重新启动任何终止进程的部分。
但是，这不是应该解决的方法。OOMD是一个丑陋的混蛋。真正的解决方案是修复交换循环导致的优先级倒置，并使内核OOM Killer在杀死进程以释放内存时更具攻击性。该修复程序属于内核，因为这是我们可以确保及时发现问题并正确杀死进程的唯一位置。
设置swappiness = 0并不是解决方案，因为当系统没有可用RAM时，无论如何它都会开始交换。没有选择来保证系统不会开始交换。
而且，修复有问题的应用程序也不是修复程序。如果用户想要利用此错误以故意使操作系统无响应，则尤其要注意。响应是内核的责任。如果Firefox使其自身无响应，则修复方法是针对该应用程序。但是，这不仅使自身无响应，而且导致整个操作系统变得非常缓慢且无响应。达到可能需要半小时才能登录到SSH的级别。SSH与它无关，如果无法运行，那就是内核中的错误，而不是系统的任何其他部分。这不是一个错误，而是两个错误。一个错误是优先级倒置，在这种情况下，脱离常规的交换周期被允许干扰有问题的进程以外的其他进程，而这本身是不好的。另一个错误是它没有 •无法检测到它处于交换循环中，并导致HDD / SSD或支持交换的任何存储设备出现疯狂磨损。交换可执行文件时，这不是问题，因为它们是只读的内存映射，不会映射回磁盘，但是kswapd0仍然被锁定，同时读取从内存中删除的内容。
哦，还有第三个错误。当需要大量内存的应用程序吞没所有可用内存时，无法保护磁盘CACHE不会被吞噬。这是kswapd0使系统无响应的原因之一。通常，最热的内存映射数据通常存储在磁盘缓存中，但是当Firefox吞噬了该缓存时，显然这意味着必须进行磁盘读取。
不一定是Firefox引起了您的问题，但它是默认的浏览器，而不是Chrome。众所周知，两者都会触发此问题，因为它们将可用内存视为浪费的东西，包括缓存和交换内存，在Linux中将其视为“可用内存”。因此，为了不浪费“可用内存”，浪费了它，将它用于缓存和其他东西。显然，将SWAP用于DISK CACHE是一个非常糟糕的想法，但是Firefox和Chrome的同伴对此做出了回应，“空闲内存浪费了内存”。
因此，我们这里有三个内核错误，内核团队似乎并未考虑这些错误。以及Firefox，Chrome和所有他们不认为是错误的派生工具中的错误。我尝试在Fedora笔记本电脑上构建Firefox，以调查此问题并可能对其进行修补。你猜怎么了。在具有4GB内存的4核CPU上使用GCC构建Firefox会触发具有优先级反转的SWAP LOOP。因此，必须重写的应用程序之一是GCC。在NetBSD上，发生的事情只是GCC的四个运行实例比运行一个实例慢，但它不会冻结系统。
是的，这有点麻烦，但我希望它可以弄清Linux内存子系统以及引起该问题的应用程序的当前问题。
如果没有交换并且kswapd0正在运行，则此时您的系统实际上正在使用几乎所有RAM。是时候获得更好的工具来监视内存使用情况了（或系统中的可用/可用内存）。
真正的解决方法是减少内存使用（运行内存泄漏较少的进程，运行较少的进程，根本不运行某些进程，限制某些服务器软件的子进程/工作进程的数量）或获取更多的RAM。如果对RAM的需求是由内存泄漏引起的，则可以选择使用swap。Linux应该很聪明，只要有足够的时间就可以交换泄漏的部分。进行交换总比没有好，但是这并不能真正替代拥有足够数量的RAM。