User:Dragonwater/Improving performance (简体中文) tmp

From ArchWiki
Jump to navigation Jump to search

Tango-edit-clear.pngThis article or section needs language, wiki syntax or style improvements. See Help:Style for reference.Tango-edit-clear.png

Warning: This page was laid aside. DON'T modify anymore.
翻译状态:本文是 Improving performance翻译。上次翻译日期:2021-06-04。如果英文版本有所更改,则您可以帮助同步翻译。

本文将介绍关于系统性能诊断的基本知识,以及优化系统性能的具体步骤。

基础工作

了解系统

性能优化的最佳方法是找到瓶颈,因为这个子系统是导致系统速度低下的主要原因。查看系统配置表可以发现瓶颈,也可以通过以下方式寻找线索:

  • 如果同时运行多个大型程序(如 LibreOffice、Firefox等)时卡顿,检查内存容量是否充足。可使用以下命令,并检查“available”列的数值:
$ free -m
  • 如果开机时间非常长,并且第一次加载应用时很慢(但是启动以后运行却很流畅),可能是硬盘问题。可以用 hdparm 命令测量硬盘速度,在硬盘空闲时执行:
注意: hdparm 只代表了硬盘的读取速度,并没有进行有效的评分。空闲时读取速度只要高于 40MB/s 就足以满足大多数系统。
$ hdparm -t /dev/sdx
  • 如果在内存充裕的情况下 CPU 占用率一直很高,可以通过停止进程或禁用 守护服务。有多种方法可以监测 CPU 负荷,例如 htoppstree 或其他 系统监视器
$ htop
  • 如果应用使用直接渲染卡顿(比如使用 GPU 的视频播放器、游戏或窗口管理器),改善 GPU 的性能应当很有效。首先需要检查直接渲染是否真的开启的。可以使用 mesa-demos 中的 glxinfo 命令:
$ glxinfo | grep "direct rendering"
direct rendering: Yes

跑分

为定量评估优化成果,可使用基准测试

存储设备

硬盘的连接方式

内部硬件路径意指储存设备是如何连接到主板的。例如 TCP/IP 经由 NIC、即插即用设备可以使用 PCIe/PCI、火线、RAID 卡 、USB 等。通过将储存设备均分到这些接口可以最大化主板的性能,比如将六个硬盘接连到 USB 要比三个连接到 USB、三个连接到火线要慢。原因是主板上的接口点类似管道,而管道同一时间的最大流量是有上限的。幸运的是主板通常会有多个管道。 比如:

  1. 使用 PCI/PCIe/ATA 直接连接到主板。
  2. Using an external enclosure to house the disk over USB/Firewire
  3. 通过 TCP/IP 将设备转换为网络存储。

此外,假设你的电脑前面有两个 USB 插口,后面有四个 USB 插口,那么前面插两个、后面插两个应当要比前面插一个、后面插三个更快。这是因为前面的插口可能是多个根 Hub 设备,也就是说它可以在同一时间发送更多的数据。使用下面的命令查看你的机器上是否有多个路径:

USB设备树
$ lsusb -tv
PCI设备树
$ lspci -tv

分区

确保你的分区是 分区对齐 的。

多硬盘

如果你有多个硬盘,那么将其设置为 RAID 可以提升速度。

在分离的硬盘上创建 交换空间 也可以带来一些帮助,尤其是使用交换空间十分频繁时。

机械硬盘布局

If using a traditional spinning HDD, your partition layout can influence the system's performance. Sectors at the beginning of the drive (closer to the outside of the disk) are faster than those at the end. Also, a smaller partition requires less movements from the drive's head, and so speed up disk operations. Therefore, it is advised to create a small partition (10GB, more or less depending on your needs) only for your system, as near to the beginning of the drive as possible. Other data (pictures, videos) should be kept on a separate partition, and this is usually achieved by separating the home directory (/home/user) from the system (/).

选择文件系统

为特定系统指定一个最好的文件系统是很重要的,因为每个文件系统都有其有点。文章 File systems (简体中文) 为流行的文件系统提供了一个摘要。你也可以查看 Category:File systems (简体中文)

挂载选项

已知 noatime 可以用于提升文件系统的性能

其他的挂载选项是文件系统指定的,因此这里有几个相关的文章:

Reiserfs

data=writeback 可用于改善速度,但是在停电时损失数据。notail 会额外占用文件系统大约 5% 的空间,但是可以改善速度。你可以在不同的磁盘中储存日志和数据以减少磁盘负载。这可以在创建文件系统时指定:

# mkreiserfs –j /dev/sda1 /dev/sdb1

使用日志分区替换 /dev/sda1 、使用数据分区替换 /dev/sdb1 。在 这个文章 里你可以看到更多关于 reiserfs 的信息。

更改内核选项

There are several key tunables affecting the performance of block devices, see sysctl#Virtual memory for more information.

I/O 调度

背景信息

The input/output (I/O) scheduler is the kernel component that decides in which order the block I/O operations are submitted to storage devices. It is useful to remind here some specifications of two main drive types because the goal of the I/O scheduler is to optimize the way these are able to deal with read requests:

  • An HDD has spinning disks and a head that moves physically to the required location. Therefore, random latency is quite high ranging between 3 and 12ms (whether it is a high end server drive or a laptop drive and bypassing the disk controller write buffer) while sequential access provides much higher throughput. The typical HDD throughput is about 200 I/O operations per second (IOPS).
  • An SSD does not have moving parts, random access is as fast as sequential one, typically under 0.1ms, and it can handle multiple concurrent requests. The typical SSD throughput is greater than 10,000 IOPS, which is more than needed in common workload situations.

If there are many processes making I/O requests to different storage parts, thousands of IOPS can be generated while a typical HDD can handle only about 200 IOPS. There is a queue of requests that have to wait for access to the storage. This is where the I/O schedulers plays an optimization role.

调度算法

One way to improve throughput is to linearize access: by ordering waiting requests by their logical address and grouping the closest ones. Historically this was the first Linux I/O scheduler called elevator.

One issue with the elevator algorithm is that it is not optimal for a process doing sequential access: reading a block of data, processing it for several microseconds then reading next block and so on. The elevator scheduler does not know that the process is about to read another block nearby and, thus, moves to another request by another process at some other location. The anticipatory I/O scheduler overcomes the problem: it pauses for a few milliseconds in anticipation of another close-by read operation before dealing with another request.

While these schedulers try to improve total throughput, they might leave some unlucky requests waiting for a very long time. As an example, imagine the majority of processes make requests at the beginning of the storage space while an unlucky process makes a request at the other end of storage. This potentially infinite postponement of the process is called starvation. To improve fairness, the deadline algorithm was developed. It has a queue ordered by address, similar to the elevator, but if some request sits in this queue for too long then it moves to an "expired" queue ordered by expire time. The scheduler checks the expire queue first and processes requests from there and only then moves to the elevator queue. Note that this fairness has a negative impact on overall throughput.

The Completely Fair Queuing (CFQ) approaches the problem differently by allocating a timeslice and a number of allowed requests by queue depending on the priority of the process submitting them. It supports cgroup that allows to reserve some amount of I/O to a specific collection of processes. It is in particular useful for shared and cloud hosting: users who paid for some IOPS want to get their share whenever needed. Also, it idles at the end of synchronous I/O waiting for other nearby operations, taking over this feature from the anticipatory scheduler and bringing some enhancements. Both the anticipatory and the elevator schedulers were decommissioned from the Linux kernel replaced by the more advanced alternatives presented below.

The Budget Fair Queuing (BFQ) is based on CFQ code and brings some enhancements. It does not grant the disk to each process for a fixed time-slice but assigns a "budget" measured in number of sectors to the process and uses heuristics. It is a relatively complex scheduler, it may be more adapted to rotational drives and slow SSDs because its high per-operation overhead, especially if associated with a slow CPU, can slow down fast devices. The objective of BFQ on personal systems is that for interactive tasks, the storage device is virtually as responsive as if it was idle. In its default configuration it focuses on delivering the lowest latency rather than achieving the maximum throughput.

Kyber is a recent scheduler inspired by active queue management techniques used for network routing. The implementation is based on "tokens" that serve as a mechanism for limiting requests. A queuing token is required to allocate a request, this is used to prevent starvation of requests. A dispatch token is also needed and limits the operations of a certain priority on a given device. Finally, a target read latency is defined and the scheduler tunes itself to reach this latency goal. The implementation of the algorithm is relatively simple and it is deemed efficient for fast devices.

内核的 I/O 调度器

While some of the early algorithms have now been decommissioned, the official Linux kernel supports a number of I/O schedulers which can be split into two categories:

  • The multi-queue schedulers are available by default with the kernel. The Multi-Queue Block I/O Queuing Mechanism (blk-mq) maps I/O queries to multiple queues, the tasks are distributed across threads and therefore CPU cores. Within this framework the following schedulers are available:
    • None, where no queuing algorithm is applied.
    • mq-deadline, the adaptation of the deadline scheduler (see below) to multi-threading.
    • Kyber
    • BFQ
  • The single-queue schedulers are legacy schedulers:
    • NOOP is the simplest scheduler, it inserts all incoming I/O requests into a simple FIFO queue and implements request merging. In this algorithm, there is no re-ordering of the request based on the sector number. Therefore it can be used if the ordering is dealt with at another layer, at the device level for example, or if it does not matter, for SSDs for instance.
    • Deadline
    • CFQ
Note: Single-queue schedulers were removed from kernel since Linux 5.0.

更改 I/O 调度器

Note: The best choice of scheduler depends on both the device and the exact nature of the workload. Also, the throughput in MB/s is not the only measure of performance: deadline or fairness deteriorate the overall throughput but may improve system responsiveness. Benchmarking may be useful to indicate each I/O scheduler performance.

To list the available schedulers for a device and the active scheduler (in brackets):

$ cat /sys/block/sda/queue/scheduler
mq-deadline kyber [bfq] none

To list the available schedulers for all devices:

$ grep "" /sys/block/*/queue/scheduler
/sys/block/pktcdvd0/queue/scheduler:none
/sys/block/sda/queue/scheduler:mq-deadline kyber [bfq] none
/sys/block/sr0/queue/scheduler:[mq-deadline] kyber bfq none

To change the active I/O scheduler to bfq for device sda, use:

# echo bfq > /sys/block/sda/queue/scheduler

The process to change I/O scheduler, depending on whether the disk is rotating or not can be automated and persist across reboots. For example the udev rule below sets the scheduler to none for NVMe, mq-deadline for SSD/eMMC, and bfq for rotational drives:

/etc/udev/rules.d/60-ioschedulers.rules
# set scheduler for NVMe
ACTION=="add|change", KERNEL=="nvme[0-9]n[0-9]", ATTR{queue/scheduler}="none"
# set scheduler for SSD and eMMC
ACTION=="add|change", KERNEL=="sd[a-z]|mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"
# set scheduler for rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"

Reboot or force udev#Loading new rules.

使用 I/O 调度器

Each of the kernel's I/O scheduler has its own tunables, such as the latency time, the expiry time or the FIFO parameters. They are helpful in adjusting the algorithm to a particular combination of device and workload. This is typically to achieve a higher throughput or a lower latency for a given utilization. The tunables and their description can be found within the kernel documentation.

To list the available tunables for a device, in the example below sdb which is using deadline, use:

$ ls /sys/block/sdb/queue/iosched
fifo_batch  front_merges  read_expire  write_expire  writes_starved

To improve deadline's throughput at the cost of latency, one can increase fifo_batch with the command:

# echo 32 > /sys/block/sdb/queue/iosched/fifo_batch

电源管理配置

When dealing with traditional rotational disks (HDD's) you may want to lower or disable power saving features completely.

减少磁盘读写

Avoiding unnecessary access to slow storage drives is good for performance and also increasing lifetime of the devices, although on modern hardware the difference in life expectancy is usually negligible.

Note: A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and 10GB of data written per day, would get an 8 years life expectancy. It gets better with bigger SSDs and modern controllers with less write amplification. Also compare [1] when considering whether any particular strategy to limit disk writes is actually needed.

显示磁盘写信息

The iotop package can sort by disk writes, and show how much and how frequently programs are writing to the disk. See iotop(8) for details.

重定位文件到 tmpfs

Relocate files, such as your browser profile, to a tmpfs file system, for improvements in application response as all the files are now stored in RAM:

文件系统

Refer to corresponding file system page in case there were performance improvements instructions, e.g. Ext4#Improving performance and XFS#Performance.

交换空间

See Swap#Performance.

同步和缓冲区大小

See Sysctl#Virtual memory for details.

使用 ionice 调度 储存 I/O

Many tasks such as backups do not rely on a short storage I/O delay or high storage I/O bandwidth to fulfil their task, they can be classified as background tasks. On the other hand quick I/O is necessary for good UI responsiveness on the desktop. Therefore it is beneficial to reduce the amount of storage bandwidth available to background tasks, whilst other tasks are in need of storage I/O. This can be achieved by making use of the linux I/O scheduler CFQ, which allows setting different priorities for processes.

The I/O priority of a background process can be reduced to the "Idle" level by starting it with

# ionice -c 3 command

See ionice(1) and [2] for more information.

CPU

超频

超频 通过增加 CPU 的最高时钟频率改善 CPU 的性能。超频的能力取决于 CPU 模型和主板模型。一般通过 BIOS 进行超频。超频具有缺点和风险。这里既不推荐也不鼓励。

很多 Intel 芯片不会在 acpi_cpufreq 或其他软件中报告真正的时钟频率。这会导致过多的 dmesq 消息,通过卸载并添加 acpi_cpufreq 内核参数可以避免此问题。

使用 i7z 中的 i7z 可以读取真实的时钟速度。对于正确的 CPU 超频方式而言,推荐使用 压力测试

调频

参见 CPU 调频.

Alternative CPU schedulers

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: MuQSS is not the only alternative scheduler. (Discuss in User talk:Dragonwater/Improving performance (简体中文) tmp)

The default CPU scheduler in the mainline Linux kernel is CFS. Alternative schedulers are available.

Tango-inaccurate.pngThe factual accuracy of this article or section is disputed.Tango-inaccurate.png

Reason: The official linux-zen package does not enable MuQSS (Bug Report) (Discuss in User talk:Dragonwater/Improving performance (简体中文) tmp)

One alternative scheduler focused on desktop interactivity and responsiveness is MuQSS, developed by Con Kolivas. MuQSS is included in the linux-zen kernel package. It is also available as a stand-alone patch or as part of the wider -ck patchset. See Linux-ck and Linux-pf for more information on the patchset.

Real-time kernel

Some applications such as running a TV tuner card at full HD resolution (1080p) may benefit from using a realtime kernel.

Adjusting priorities of processes

See also nice(1) and renice(1).

Ananicy

Ananicy is a daemon, available in the ananicy-gitAUR package, for auto adjusting the nice levels of executables. The nice level represents the priority of the executable when allocating CPU resources.

cgroups

See cgroups.

Cpulimit

Cpulimit is a program to limit the CPU usage percentage of a specific process. After installing cpulimit, you may limit the CPU usage of a processes' PID using a scale of 0 to 100 times the number of CPU cores that the computer has. For example, with eight CPU cores the precentage range will be 0 to 800. Usage:

$ cpulimit -l 50 -p 5081

irqbalance

The purpose of irqbalance is distribute hardware interrupts across processors on a multiprocessor system in order to increase performance. It can be controlled by the provided irqbalance.service.

Turn off CPU exploit mitigations

Warning: Do not apply this setting without considering the vulnerabilities it opens up. See this and this for more information.

Turning off CPU exploit mitigations improves performance (sometimes up to 50%). Use below kernel parameter to disable them all:

mitigations=off

The explanations of all the switches it toggles are given at kernel.org. You can use spectre-meltdown-checkerAUR for vulnerability check.

图形

Xorg 配置

图形性能获取依赖于 xorg.conf(5) 中的设置。参见 NVIDIAATIAMDGPUIntel

不正确的配置可能会导致 Xorg 停止工作,请谨慎配置。

Mesa 配置

The performance of the Mesa drivers can be configured via drirc. GUI configuration tools are available:

  • adriconf (Advanced DRI Configurator) — GUI tool to configure Mesa drivers by setting options and writing them to the standard drirc file.
https://gitlab.freedesktop.org/mesa/adriconf/ || adriconf
  • DRIconf — Configuration applet for the Direct Rendering Infrastructure. It allows customizing performance and visual quality settings of OpenGL drivers on a per-driver, per-screen and/or per-application level.
https://dri.freedesktop.org/wiki/DriConf/ || driconfAUR

超频

于 CPU 类似,超频可以直接提升性能,但是并不推荐。AUR 中的包 amdoverdrivectrlAUR (旧 AMD/ATI 显卡)、 rocm-smi-lib64AUR (新 AMD 显卡), nvclockAUR (Geforce 9之前的 NVIDIA 显卡)、nvidia-utils (新的 NVIDIA 显卡)。

参阅 AMDGPU_(简体中文)#OverclockingNVIDIA/Tips and tricks#Enabling overclocking

Enabling PCI Resizable BAR

The PCI specification allows larger Base Address Registers to be used for exposing PCI devices memory to the PCI Controller. This can result in a performance increase for video cards. Having access to the the full vRAM improves performance, but also enables optimizations in the graphics driver. The combination of resizable BAR, above 4G encoding and these driver optimizations are what AMD calls AMD Smart Access Memory, currently available on AMD Series 500 chipset motherboards. This setting may not be available on all motherboards, and is known to sometimes cause boot problems on certain boards.

If the BAR has a 256M size, the feature is not enabled or not supported:

# dmesg | grep BAR=
[drm] Detected VRAM RAM=8176M, BAR=256M

To enable it, enable the setting named "Above 4G Decode" or ">4GB MMIO" in your motherboard settings. Verify that the BAR is now larger:

# dmesg | grep BAR=
[drm] Detected VRAM RAM=8176M, BAR=8192M

内存、交换空间 和 OOM 控制

Clock frequency and timings

RAM can run at different clock frequencies and timings, which can be configured in the BIOS. Memory performance depends on both values. Selecting the highest preset presented by the BIOS usually improves the performance over the default setting. Note that increasing the frequency to values not supported by both motherboard and RAM vendor is overclocking, and similar risks and disadvantages apply, see #Overclocking.

Root on RAM overlay

If running off a slow writing medium (USB, spinning HDDs) and storage requirements are low, the root may be run on a RAM overlay ontop of read only root (on disk). This can vastly improve performance at the cost of a limited writable space to root. See liverootAUR.

zram 或 zswap

内核模块 zram(以前叫做 compcache)在内存中提供了一个压缩块。若你将其用作交换空间,则内存可以保存更多的数据,代价是消耗更多的 CPU 。但是它仍然比硬盘上的交换空间快得多。若一个系统经常使用交换空间,使用 zram 可以提高响应。使用 zram 也可以减少对磁盘的读写,当交换空间被设置到固态硬盘时,这可以增加固态硬盘的寿命。

zswap 可以带来相似的益处(和相似的代价)。两者不同的是 zswap 将页面压缩后换入交换空间,而 zram 则换入内存。

例如:设置一个使用 lz4 压缩算法的 32GB 的、高优先级的 zram:

# modprobe zram
# echo lz4 > /sys/block/zram0/comp_algorithm
# echo 32G > /sys/block/zram0/disksize
# mkswap --label zram0 /dev/zram0
# swapon --priority 100 /dev/zram0

要禁用它,可以重启或者:

# swapoff /dev/zram0
# rmmod zram

详细的描述提供在 zram 模块的官方文档

zram-generator 提供了一个 systemd-zram-setup@.service 单元用来自动初始化 zram 设备。此单元无需被 [enable/start]。以下资源提供了使用它的必要信息:

“生成器将会在系统启动的早期被 systemd 调用”,因此使用它只需要创建配置文件并重启。这里提供了一个简单的配置:/usr/share/doc/zram-generator/zram-generator.conf.example 。你可以通过检查 swap 的状态 或通过检查 systemd-zram-setup@zramN.service状态 来检查 zram 的情况。这里 /dev/zramN 是配置文件中设定的内容。

此外,zramdAUR 默认以 zstd 算法自动设置 zram 。其配置文件位于 /etc/default/zramd 并且需要 启用 zramd.service 服务。

使用 udev 规则设置 zram

The example below describes how to set up swap on zram automatically at boot with a single udev rule. No extra package should be needed to make this work.

First, enable the module:

/etc/modules-load.d/zram.conf
zram

Configure the number of /dev/zram nodes you need.

/etc/modprobe.d/zram.conf
options zram num_devices=2

Create the udev rule as shown in the example.

/etc/udev/rules.d/99-zram.rules
KERNEL=="zram0", ATTR{disksize}="512M" RUN="/usr/bin/mkswap /dev/zram0", TAG+="systemd"
KERNEL=="zram1", ATTR{disksize}="512M" RUN="/usr/bin/mkswap /dev/zram1", TAG+="systemd"

Add /dev/zram to your fstab.

/etc/fstab
/dev/zram0 none swap defaults 0 0
/dev/zram1 none swap defaults 0 0

使用显存

In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See Swap on video RAM.

改善系统在低内存情况下的响应速度

On traditional GNU/Linux system, especially for graphical workstations, when allocated memory is overcommitted, the overall system's responsiveness may degrade to a nearly unusable state before either triggering the in-kernel OOM-killer or a sufficient amount of memory got free (which is unlikely to happen quickly when the system is unresponsive, as you can hardly close any memory-hungry applications which may continue to allocate more memory). The behaviour also depends on specific setups and conditions, returning to a normal responsive state may take from a few seconds to more than half an hour, which could be a pain to wait in serious scenario like during a conference presentation.

While the behaviour of the kernel as well as the userspace things under low-memory conditions may improve in the future as discussed on kernel and Fedora mailing lists, users can use more feasible and effective options than hard-resetting the system or tuning the vm.overcommit_* sysctl parameters:

  • Manually trigger the kernel OOM-killer with Magic SysRq key, namely Alt+SysRq+f.
  • Use a userspace OOM daemon to tackle these automatically (or interactively).
Warning: Triggering OOM killer to kill running applications may lose your unsaved works. It is up to you that either you are patient enough to wait in hope that applications will finally free the memory normally, or you want to bring back unresponsive system as soon as possible.

Sometimes a user may prefer OOM daemon to SysRq because with kernel OOM-killer you cannot prioritize the process to (or not) terminate. To list some OOM daemons:

  • systemd-oomd — Provided by systemd as systemd-oomd.service that uses cgroups-v2 and pressure stall information (PSI) to monitor and take action on processes before an OOM occurs in kernel space.
https://github.com/systemd/systemd, systemd-oomd(8) || systemd
  • earlyoom — Simple userspace OOM-killer implementation written in C.
https://github.com/rfjakob/earlyoom || earlyoom
  • oomd — OOM-killer implementation based on PSI, requires Linux kernel version 4.20+. Configuration is in JSON and is quite complex. Confirmed to work in Facebook's production environment.
https://github.com/facebookincubator/oomd || oomdAUR
  • nohang — Sophisticated OOM handler written in Python, with optional PSI support, more configurable than earlyoom.
https://github.com/hakavlad/nohang || nohang-gitAUR
  • low-memory-monitor — GNOME developer's effort that aims to provides better communication to userspace applications to indicate the low memory state, besides that it could be configured to trigger the kernel OOM-killer. Based on PSI, requires Linux 5.2+.
https://gitlab.freedesktop.org/hadess/low-memory-monitor/ || low-memory-monitor-gitAUR

网络

Watchdogs

According to Wikipedia:Watchdog timer:

A watchdog timer [...] is an electronic timer that is used to detect and recover from computer malfunctions. During normal operation, the computer regularly resets the watchdog timer [...]. If, [...], the computer fails to reset the watchdog, the timer will elapse and generate a timeout signal [...] used to initiate corrective [...] actions [...] typically include placing the computer system in a safe state and restoring normal system operation.

Many users need this feature due to their system's mission-critical role (i.e. servers), or because of the lack of power reset (i.e. embedded devices). Thus, this feature is required for a good operation in some situations. On the other hand, normal users (i.e. desktop and laptop) do not need this feature and can disable it.

To disable watchdog timers (both software and hardware), append nowatchdog to your boot parameters.

To check the new configuration do:

# cat /proc/sys/kernel/watchdog

or use:

# wdctl

After you disabled watchdogs, you can optionally avoid the loading of the module responsible of the hardware watchdog, too. Do it by blacklisting the related module, e.g. iTCO_wdt.

Note: Some users reported the nowatchdog parameter does not work as expected but they have successfully disabled the watchdog (at least the hardware one) by blacklisting the above-mentioned module.

Either action will speed up your boot and shutdown, because one less module is loaded. Additionally disabling watchdog timers increases performance and lowers power consumption.

See [3], [4], [5], and [6] for more information.

参见