我的Raspberry Pi（现在距离我10,000公里）的工作原理如下：

• 它运行的是 Raspbian（2016 年 7 月的版本）
• SD 卡包含/boot
• 加密的硬盘驱动器（使用 LUKS cryptsetup）包含/
• 当 Pi 启动时，我可以通过 SSH 远程解锁 HDD dropbear。它要求输入 HDD 的密码，然后启动顺序将正常继续。

有关我如何完成这一切的更多信息，请阅读http://blog.romainpellerin.eu/raspberry-pi-the-ultimate-guide.html。
TL;DR这是一个简化版本：

apt-get install busybox cryptsetup rsync
echo "initramfs initramfs.gz 0x00f00000" >> /boot/config.txt
sed -e "s|root=/dev/mmcblk0p2|root=/dev/mapper/hddcrypt cryptdevice=/dev/sda1:hddcrypt|" -i /boot/cmdline.txt
sed -e "s|/dev/mmcblk0p2|/dev/mapper/hddcrypt|" -i /etc/fstab
echo -e "hddcrypt\t/dev/sda1\tnone\tluks" >> /etc/crypttab
cryptsetup --verify-passphrase -c aes-xts-plain64 -s 512 -h sha256 luksFormat /dev/sda1
mkinitramfs -o /boot/initramfs.gz $(uname -r)
aptitude install dropbear
// Configuring the SSH access …

内核中如何处理信号。如果我向内核线程/进程发送终止信号，内部会发生什么。内核进程崩溃是否意味着内核总是出现恐慌，如果不是，它会生成 coredump。

内核架构和操作系统架构有什么区别？当试图找出要为哪种架构编译二进制文件时，其中哪一个是相关的？

据我所知，尽管在某些发行版中使用 32 位操作系统，但仍可以安装 64 位内核。

打印什么uname -i，内核架构还是操作系统架构？dpkg --print-architecture和呢arch？

我将内核从 3.10.0-514.26.2.el7.x86_64 更新到 3.10.0-693.11.6.el7.x86_64 我注意到 3.10.0-693.11.6.el7.x86_64 中的所有内核模块现在都附加了“.xz”（下面的示例输出）

/usr/lib/modules/3.10.0-693.11.6.el7.x86_64/kernel/sound/soc/intel/skylake/snd-soc-skl-ipc.ko.xz
/usr/lib/modules/3.10.0-693.11.6.el7.x86_64/kernel/sound/soc/intel/skylake/snd-soc-skl.ko.xz
/usr/lib/modules/3.10.0-693.11.6.el7.x86_64/kernel/sound/soc/snd-soc-core.ko.xz
/usr/lib/modules/3.10.0-693.11.6.el7.x86_64/kernel/sound/soundcore.ko.xz
/usr/lib/modules/3.10.0-693.11.6.el7.x86_64/kernel/sound/synth/emux/snd-emux-synth.ko.xz
/usr/lib/modules/3.10.0-693.11.6.el7.x86_64/kernel/sound/synth/snd-util-mem.ko.xz
/usr/lib/modules/3.10.0-693.11.6.el7.x86_64/kernel/sound/usb/6fire/snd-usb-6fire.ko.xz
/usr/lib/modules/3.10.0-693.11.6.el7.x86_64/kernel/sound/usb/bcd2000/snd-bcd2000.ko.xz
/usr/lib/modules/3.10.0-693.11.6.el7.x86_64/kernel/sound/usb/caiaq/snd-usb-caiaq.ko.xz
/usr/lib/modules/3.10.0-693.11.6.el7.x86_64/kernel/sound/usb/hiface/snd-usb-hiface.ko.xz

但就之前的版本而言，一切仍然只是标准的 *.ko

/usr/lib/modules/3.10.0-229.7.2.el7.x86_64/kernel/sound/synth/emux/snd-emux-synth.ko
/usr/lib/modules/3.10.0-229.7.2.el7.x86_64/kernel/sound/synth/snd-util-mem.ko
/usr/lib/modules/3.10.0-229.7.2.el7.x86_64/kernel/sound/usb/6fire/snd-usb-6fire.ko
/usr/lib/modules/3.10.0-229.7.2.el7.x86_64/kernel/sound/usb/caiaq/snd-usb-caiaq.ko
/usr/lib/modules/3.10.0-229.7.2.el7.x86_64/kernel/sound/usb/misc/snd-ua101.ko
/usr/lib/modules/3.10.0-229.7.2.el7.x86_64/kernel/sound/usb/snd-usb-audio.ko
/usr/lib/modules/3.10.0-229.7.2.el7.x86_64/kernel/sound/usb/snd-usbmidi-lib.ko
/usr/lib/modules/3.10.0-229.7.2.el7.x86_64/kernel/sound/usb/usx2y/snd-usb-us122l.ko
/usr/lib/modules/3.10.0-229.7.2.el7.x86_64/kernel/sound/usb/usx2y/snd-usb-usx2y.ko

当我实际尝试解压缩 ko.xz 时，看起来它们命名错误并且实际上并未压缩

tar -xJf ip_gre.ko.xz
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors

xz -l 将文件显示为“压缩”

 xz -l ip_gre_default.ko.xz
Strms  Blocks   Compressed Uncompressed  Ratio  Check   Filename
    1       1      8,924 B     32.2 KiB  0.271  CRC64   ip_gre_default.ko.xz

这是否意味着 …

我想问一下关于 的输出的问题sar -q。如果有人能帮助我理解，我将不胜感激runq-sz。

8 cpu threads我有一个 cpu 线程打开的系统 RHEL 7.2。

[ywatanabe@host2 ~]$ cat /proc/cpuinfo | grep processor | wc -l
8

以下是sar -q 我的系统的结果，但与 相比runq-sz似乎较低ldavg-1。

                runq-sz  plist-sz   ldavg-1   ldavg-5  ldavg-15   blocked
05:10:01 PM         0       361      0.29      1.68      2.14         0
05:11:01 PM         0       363      1.18      1.61      2.08         2
05:12:01 PM         0       363      7.03      3.15      2.58         1
05:13:01 PM         0       365      8.12      4.15      2.96         1
05:14:01 PM         3       371      7.40 …

Windows 10 支持 Intel 速度转换。

Linux（内核）也支持吗？

变速相关信息：

https://www.anandtech.com/show/9751/examining-intel-skylake-speed-shift-more-responsive-processors

sock中定义的结构体有sock.h两个看起来非常相似的属性：

• sk_wmem_alloc，定义为“已提交的传输队列字节”
• sk_wmem_queued，定义为“持久队列大小”

对我来说，这sk_wmem_alloc是当前分配给发送队列的内存量。但那么，什么是sk_wmem_queued？

参考

• 根据StackOverflow 的回答：

  wmem_queued：在传输队列中排队且尚未发送或尚未确认的套接字发送缓冲区使用的内存量。

• 该ss男子还给出了定义，但并没有真正启发我（我不明白IP层与此有什么关系）：

  wmem_alloc：用于发送数据包（已发送到第 3 层）的内存 wmem_queued：用于发送数据包（尚未发送到第 3 层）分配的内存

• 已经有人在 LKML 上问过类似的问题，但没有得到答案
• 手册sock_diag(7)页也对这些属性有自己的定义：

  SK_MEMINFO_WMEM_ALLOC：发送队列中的数据量。 SK_MEMINFO_WMEM_QUEUED：TCP 排队但尚未发送的数据量。

所有这些定义都是不同的，并且没有一个清楚地解释_alloc和_queued变体如何不同。

上游内核和下游内核有什么区别？

上游内核是指最新的内核。但是下游内核呢？

我总是读到/听说上下文切换的成本很高。我最近开始阅读 Robert Love 的“Linux 内核开发”，并完成了“进程和进程调度”一章。这让我对不同进程和线程之间的上下文切换成本有了一些了解（因为线程被视为进程）。我想解决这个问题，真正了解上下文切换的成本，最好是粗略地了解指令数量和时间损失。

为了简单起见，我们假设一个单核处理器正在运行两个具有相同良好权重的进程（proc1 和 proc2）。另外，假设目标延迟为 20 毫秒，因此每个进程的调度时间为 10 毫秒。当context_switch发生时，我假设当context_switch发生时，proc1 被挂起。此时proc2也暂停了？那么这是否意味着活动进程是某个内核线程或进程？如果是这样的话，这是否意味着 proc1 和 proc2 都无法在 Targeted_latency 内获得 10 毫秒的运行时间？例如（数字仅用于演示）：

+-----------20ms-----------+

|---proc1---|--|---proc2---|
^____9ms____^__^____9ms____^
             |
            2ms of kernel executing context_switch()

如果发生这种情况，从一个进程到另一个进程的context_switch()最终是否会调用context_switch()两次？一次从内核线程进入proc1，然后另一个从内核线程进入proc2？

unattended-upgrades在 Ubuntu 中会自动安装包括内核在内的安全更新，但不会自动重新启动（没关系，我不需要/想要自动重新启动）。

我怎样才能知道是否the running kernel = the latest installed kernel？

我可以通过以下方式获取当前的内核版本：

$ uname -r
5.4.0-104-generic

最新安装的内核可以通过以下方式找到：

$ dpkg -s linux-image-generic | awk '/Version:/{print $2}'
5.4.0.104.108

这两个不匹配。我可以使用 bash 魔法来比较这两个字符串（然后.108需要继续 - 为什么？），但我更喜欢使用标准的东西。