海爾滾筒洗衣機err8故障(海爾滾筒洗衣機報故障err7)

海爾滾筒洗衣機err8故障(海爾滾筒洗衣機報故障err7)

前沿拓展：

---

SUSE Labs 團隊探索了 Kernel CPU 隔離及其核心組件之一：Full Dynticks（或 Nohz Full），并撰寫了本系列文章：

1. CPU 隔離 – 簡介

2. CPU 隔離 – Full Dynticks 深探

3. CPU 隔離 – Nohz_full

4. CPU 隔離 – 管理和權衡

5. CPU 隔離 – 實踐

本文是第五篇。

我們通過前面四篇文章初步掌握了理論概念，現在終于到了實踐階段。本實踐操作共配置了 8 個 CPU，將以完全隔離的方式在第 8 個 CPU 上運行一個無意義的用戶空間循環，即：不受任何干擾。

內核配置要求

如果您運行的是 SUSE Linux Enterprise Server 15 SP3 (https://documentation.suse.com/sles/15SP3/) 或更高版本，則無需擔心這一問題；否則，一定要保證：

CONFIG_NO_HZ_FULL=y

CONFIG_CPUSETS=y

CONFIG_TRACING=y

第一條為在運行一個任務時停止 Tick 提供支持。第二條使任務綁定設置更容易。第三個選項支持對 CPU 隔離進行調試的跟蹤能力。

引導要求

使用“nohz_full=” 引導參數，可以在運行單個任務時關閉計時器 Tick，并且大多數非內核負載也會遷移到隔離范圍之外的 CPU。由于計劃隔離第 8 個 CPU，我們需要通過以下信息引導內核：

nohz_full=7

CPU 編號從 0 開始，所以第 8 個 CPU 的編號為 7。此外，無需設置“rcu_nocbs=” 引導參數，如示例中通常顯示的那樣，nohz_full 可自動調節該參數。

任務綁定

有多種方法可以在隔離的任務和系統其余部分之間劃分 CPU，首選方法是使用 cpuset (https://www.kernel.org/doc/html/latest/adminguide/cgroupv1/cpusets.html)。對于有特殊需求的人，還有其他解決方案可用。

Cpuset

一旦內核啟動，為了確保無關任務不會干擾 CPU 7，我們創建兩個 cpusets 分區。名為“isolation” 的目錄包含我們隔離的 CPU，它將來會運行隔離任務。另一個名為“housekeeping” 的目錄承擔常規負載。我們強制禁用“isolation” 分區的負載平衡，以確保任何任務都不能遷移進/出 CPU 7，除非手工移動。

在本例中，我們在 SUSE Linux Enterprise Server 15 SP3 上使用默認的 cpuset 掛載點(https://documentation.suse.com/sles/15SP3/)。

cd /sys/fs/cgroup/cpuset

mkdir housekeeping

mkdir isolated

echo 06 > housekeeping/cpuset.cpus

echo 0 > housekeeping/cpuset.mems

echo 7 > isolated/cpuset.cpus

echo 0 > isolated/cpuset.memse

cho 0 > cpuset.sched_load_balance

echo 0 > isolated/cpuset.sched_load_balance

while read P

do

echo $P > housekeeping/cgroup.procs

done < cgroup.procs

對 housekeeping/cgroup.procs 的一些寫入操作可能會失敗，因為內核線程 pid 無法移出根 cpuset 分區。然而，未綁定的內核線程會自動強制綁定 nohz_full 范圍之外的 CPU，因此可以安全地忽略這些故障。

Isolcpus

您還可以使用“isolcpus=” (https://www.suse.com/support/kb/doc/?id=000017747) 內核引導參數實現與以上 cpuset 設置相同的設置。但我們不建議使用這種解決方案，因為以后無法在運行時更改隔離配置。因此，盡管“isolcpus” 仍在使用，但一般“不推薦”。對于尚未支持 cpusets/cgroups 的專用或嵌入式內核，它可能仍然可用。

Taskset, sched_setaffinity(), …

從底層來講，還可以使用 taskset(https://man7.org/linux/manpages/man1/taskset.1.html) 等工具或者依賴 sched_setaffinity() (https://man7.org/linux/manpages/man2/sched_setaffinity.2.html) 這樣的 API，將每個任務綁定到所需的 CPU 集合。在不支持 cpuset 的系統中，其優點是允許在運行時更改綁定關系，這與“isolcpus” 不同；缺點是它需要更精細的工作。

IRQ 綁定

我們已經進行了任務綁定，但是硬件中斷仍然可以在隔離的 CPU 上觸發，并干擾其獨占負載。所幸，我們可以通過 procfs (https://www.kernel.org/doc/html/latest/coreapi/irq/irqaffinity.html)提供的接口安排在內務管理集上觸發這些中斷：

Migrate irqs to CPU 06 (exclude CPU 7)

for I in $(ls /proc/irq)

do

if [[ d &34;/proc/irq/$I&34; ]]

then

echo &34;Affining vector $I to CPUs 06&34;

echo 06 > /proc/irq/$I/smp_affinity_list

fi

done

您可能會在其中一個中斷向量上遇到 I/O 錯誤，例如 x8664 機器上的數字 0，因為這是每個 CPU 上的計時器向量表，由于其本地性的特質，無法將其移開。然而，這個問題大可放心忽略，因為“nohz_full” 就是專門為解決這個問題而設計的。

防止其他干擾

在本例中，我們處理的是基于調度程序和中斷的直接干擾。更高階的話題將在后續文章中介紹，例如防止頁面錯誤等異常(https://man7.org/linux/manpages/man2/mlock.2.html)。

實際測試

現在，大部分內務管理工作負載應在 CPU 06 上運行。CPU 7 將在無干擾的情況下運行用戶空間代碼。我們用啟動器做一個無意義的循環。

虛擬用戶空間循環

以下代碼將當前任務綁定到隔離的 cpuset（即 cpu7），并始終執行一個死循環。它在啟動并運行 10 秒后，最終被單獨的啟動器啟關閉。

include <stdio.h>

include <fcntl.h>

include <unistd.h>

include <errno.h>

int main(void)

{

// Move the current task to the isolated cgroup (bind to CPU 7)

int fd = open(&34;/sys/fs/cgroup/cpuset/isolated/cgroup.procs&34;, O_WRONLY);

if (fd < 0) {

perror(&34;Can&39;t open cpuset file...\n&34;);

return 0;

}

write(fd, &34;0\n&34;, 2);

close(fd);

// Run an endless dummy loop until the launcher kills us

while (1)

;

return 0;

}

將該代碼包寫在名為“user_loop.c” 的文件中，并編譯：

$ gcc user_loop.c o user_loop

啟動器

除了在隔離的 CPU 7 上運行無意義的循環 10 秒之外，啟動器的作用是跟蹤可能對敏感工作負載有潛在干擾的事件。在本例中，我們使用 SUSE Linux Enterprise Server 15 SP3 上默認的跟蹤 debugfs 裝載點：

TRACING=/sys/kernel/debug/tracing/

Make sure tracing is off for now

echo 0 > $TRACING/tracing_on

Flush previous traces

echo > $TRACING/trace

Record disturbance from other tasks

echo 1 > $TRACING/events/sched/sched_switch/enable

Record disturbance from interrupts

echo 1 > $TRACING/events/irq_vectors/enable

Now we can start tracingecho 1 > $TRACING/tracing_on

Run the dummy user_loop for 10 seconds on CPU 7

./user_loop &

USER_LOOP_PID=$!

sleep 10

kill $USER_LOOP_PID

Disable tracing and save traces from CPU 7 in a file

echo 0 > $TRACING/tracing_on

cat $TRACING/per_cpu/cpu7/trace > trace.7

這里跟蹤到兩個有意思的底層事件：

調度程序上下文切換：報告任何搶占“user_loop” 的任務。這包括工作隊列和內核線程。IRQ 向量：報告任何（大多數）中斷“user_loop” 的 IRQ，這包括計時器中斷。

上述代碼可以寫入名為“launch” 的文件中，該文件與“user_loop” 位于相同的目錄中。

完美世界的理想結果

在以 root 身份運行上述“launch” 之后，如果一切順利，可以在“trace.7” 文件中找到以下內容：

<idle>0 [007] d..2. 1980.976624: sched_switch: prev_comm=swapper/7 prev_pid=0

prev_prio=120 prev_state=R ==> next_comm=user_loop next_pid=1553

next_prio=120

user_loop1553 [007] d.h.. 1990.946593: reschedule_entry: vector=253

user_loop1553 [007] d.h.. 1990.946593: reschedule_exit: vector=253

在這里，user_loop 任務從時間戳 1980 秒處開始第一次跟蹤，從 swapper（空閑任務）進行調度。然后，在 10 秒鐘內(1990 – 1980)，直到任務最終中斷之前，任何事情都沒有發生，這樣做是為了處理發射器發送的關閉信號。這表明在這段時間內沒有任務或中斷干擾我們的 user_loop。

請注意：只有在完美世界中的完美機器上進行理想設置時，才會出現這種結果。

了解更多軟件開發與相關領域知識，點擊訪問 InfoQ 官網：https://www.infoq.cn/，獲取更多精彩內容！

拓展知識：