戴文的Linux內核專題：06 內核配置(2)

這一部分我們講配置內核IRQ子系統。中斷請求(IRQ)是硬體發給處理器的一個信號，它暫時停止一個正在運行的程序並允許一個特殊的程序佔用CPU運行。

這個目錄中的第一個問題屬於內核特性(Expose hardware/virtual IRQ mapping via debugfs (IRQ_DOMAIN_DEBUG))（通過debugfs來顯示硬體/虛擬的IRQ映射），它詢問是否可以使用虛擬的調試文件系統來映射硬體及Linux上對應的IRQ中斷號。這個用作調試目的，大多數用戶不需要用到，所以我選擇了"no"。

下一個標題顯示"Timers subsystem"（計時器子系統）。第一個有關定時器子系統的問題是「Tickless System (Dynamic Ticks) (NO_HZ)」（無滴答系統）。我選擇了「yes」，這會啟用一個無滴答系統。這意味著定時器中斷將會按需使用，定時器中斷允許任務以特定的時間間隔執行。下一個問題(High Resolution Timer Support (HIGH_RES_TIMERS))問是否支持高精度定時器。並不是所有的硬體支持這個，通常地說，如果硬體很慢或很舊，那麼選擇"no",否則像我一樣選擇"yes"。

下一個標題"CPU/Task time and stats accounting"（CPU/任務用時與狀態統計），這個是關於進程的追蹤。第一個問題看上去像這樣：

Cputime accounting （CPU用時統計）

1. Simple tick based cputime accounting (TICK_CPU_ACCOUNTING) （簡單基於滴答的用時統計）
2. Full dynticks CPU time accounting (VIRT_CPU_ACCOUNTING_GEN) (NEW) （全動態滴答的用時統計）
3. Fine granularity task level IRQ time accounting (IRQ_TIME_ACCOUNTING) （細粒度的任務級IRQ用時統計）

TICKCPUACCOUNTING會在每個CPU滴答中檢測/proc/stat。這是默認的選項，這個記賬方法非常簡單。

注意：CPU滴答是抽象測量CPU時間的方式。每個處理器、操作系統和安裝的系統都不同，比如說，一個更強大的處理器會比老的處理器擁有更多的CPU滴答。如果你安裝了一個Linux系統，然後接著在同一塊磁碟上重新安裝了它，你可能會得到一個更快或更慢的CPU滴答時間(至少一些計算機技術書上這麼說)。通常來講，一個更快的時鐘速度意味著更多的CPU滴答。

如果啟用了VIRT_CPU_ACCOUNTING_GEN，任務和CPU時間統計將由監視內核-用戶邊界實現。這個選擇的代價是會增加額外的開銷。

IRQ_TIME_ACCOUNTING記賬方式則通過檢測IRQ狀態間的時間戳工作，這個性能開銷很小。

我選擇了"1"並被詢問有關BSD記賬"BSD Process Accounting (BSD_PROCESS_ACCT)"（BSD進程記賬）的問題。這個內核特性會記錄每個進程不同的關閉信息。為了得到一個更小和更快的內核，我選擇了"no".

下一組問題看上去就像下面這樣。

• Export task/process statistics through netlink (TASKSTATS) （通過netlink導出任務/進程統計數據）
• Enable per-task delay accounting (TASK_DELAY_ACCT) （啟用針對每個任務的延遲統計）
• Enable extended accounting over taskstats (TASK_XACCT) （啟用taskstats的擴展統計）

TASKSTATS使內核可以通過網路套接字導出進程統計。網路套接字是內核和用戶空間進程間IPC通信的一種形式。TASKDELAYACCT監視進程並注意資源訪問的延遲。比如，TASKDELAYACCT可以看到X進程正在為了CPU時間而等待，如果TASK_DELAY_ACCT觀察到進程已經等待了太長時間，這個進程接著就會被給予一些CPU時間。TASK_XACCT會收集額外的統計數據，為了更小的內核負載我會禁用這個。

現在接下來的目錄就會顯示RCU子系統：讀取-複製-更新子系統是一種低負載的同步機制，它允許程序查看到正在被修改/更新的文件。配置工具已經回答了第一個問題。

RCU Implementation （RCU 實現方式）

1. Tree-based hierarchical RCU (TREE_RCU) （樹形分層結構的RCU）

choice[1]: 1

這裡就選擇「1」。除了TREE_RCU，還有classic RCU(更老的實現)。下一個問題(Consider userspace as in RCU extended quiescent state (RCU_USER_QS) [N/y/?])（是否在用戶空間記錄擴展的quiescent狀態）問RCU是否可以在CPU運行在用戶空間時設置一個特殊的quiescent狀態。這個選項通常被禁用，因為這會增加太多消耗。下面是另一個RCU問題(Tree-based hierarchical RCU fanout value (RCU_FANOUT) [64])（樹形分層結構的RCU端點數），問的是關於端點數。下一個問題(Tree-based hierarchical RCU leaf-level fanout value (RCU_FANOUT_LEAF) [16])（樹形分層結構的RCU葉級端點數），是另外一個關於端點數的問題，但它只處理葉級。還有另外一個RCU問題(Disable tree-based hierarchical RCU auto-balancing (RCU_FANOUT_EXACT) [N/y/?])（是否禁用樹形分層結構的RCU的自動平衡），詢問是否禁用RCU自動平衡樹，而採用上述的端點數。

接下來，配置腳本將會詢問"Accelerate last non-dyntick-idle CPU's grace periods (RCU_FAST_NO_HZ)"（加速最後的非dyntick-idle CPU的RCU寬限期）。在這之後會顯示"Offload RCU callback processing from boot-selected CPUs (RCU_NOCB_CPU)"（從選擇引導的CPU裡面卸載RCU回調）。（譯註：此處作者沒做解釋。前一個能夠節省電力，但是降低了性能；後一個用於調試。）

下一個問題非常重要(Kernel .config support (IKCONFIG))（內核的.config支持）。開發人員可以選擇保存由這個配置工具生成的設置到一個文件中。這個文件可以放在內核中，也可在一個模塊中，或者完全不保存。這個文件可以被想要編譯一個完全跟某人相同內核的開發者使用。這個文件還可以幫助開發人員使用一個更新的編譯器重新編譯一個內核。舉例來說，開發人員配置並編譯了一個內核，然而編譯器有一些bug，但開發人員仍然需要一個使用這些設置的內核。而值得慶幸的是，開發人員可以升級他們的編譯器，並使用設置文件來節省他們重新配置內核的時間。開發人員也可以在另一台計算機上保存源代碼和配置文件並編譯內核。至於另一個目的，開發人員可以載入該文件，並根據需要調整設置。我選擇保存配置文件在一個模塊中，這個問題 "Enable access to .config through /proc/config.gz (IKCONFIG_PROC)"（啟用通過/proc/config.gz來訪問.config的功能）是詢問這個文件是否是可以通過這次方式訪問的，我選擇了"yes"。

下一個問題是內核使用多大的log緩衝區(Kernel log buffer size (16 => 64KB, 17 => 128KB) (LOG_BUF_SHIFT) [17])（內核日誌緩衝區大小）。小的緩衝區意味著它無法像更大的緩衝區那樣保持日誌更長的時間。這個選擇取決於開發者想要日誌保持的時間，我選擇的是"12"。

接著，出現了另外一個問題。該問題詢問關於是否啟用NUMA(非一致性內存訪問)的內存/任務的均衡(Automatically enable NUMA aware memory/task placement (NUMA_BALANCING_DEFAULT_ENABLED))（自動啟用NUMA的內存/任務均衡）。如果在NUMA的機器上設置了該選項，那麼NUMA自動平衡就會啟用。在NUMA下，處理器可以比非本地內存(內存分配給另外一個處理器或在處理器之間共享的內存)更快地訪問它的本地內存。如果上面啟用了(我啟用了)，那麼最好對這個問題"Memory placement aware NUMA scheduler (NUMA_BALANCING)"（由NUMA調度器進行內存分配）回答"yes"，這是一個NUMA調度器。

在新的標題"Control Group support"（Cgroup支持）下，因為先前的選擇，"Control Group support (CGROUPS)"（Cgroup支持）被自動地回答了"yes"。

以下設定(Example debug cgroup subsystem (CGROUP_DEBUG))（導出Cgroup子系統的調試信息）是啟用一個用於調試cgroup框架的一個簡單cgroup子系統。下一個選項(Freezer cgroup subsystem (CGROUP_FREEZER))（凍結Cgroup子系統）可以讓程序員可以凍結或解凍cgroup內的任務。

注意：cgroup是一組進程。

下面我們要求回答"Device controller for cgroups (CGROUP_DEVICE)"(Cgroup的設備控制器)。cgroup(控制組)是一種用來控制資源使用的特性。回答"yes"可以允許設備cgroup的白名單可以使用open和mknod系統調用(用來創建文件系統節點的系統調用)。

下一個問題(Cpuset support (CPUSETS))（CPU分組支持）詢問的是內核是否可以創建和管理CPU分組。這允許管理員可以在一個系統上動態分配各組內存節點，並分配任務在這些內存上運行。這通常用於SMP和NUMA系統中。我這個問題回答的是"no"。

注意：請記住，如果我沒有指定我選的是什麼，那麼我選的就是默認選項。

啟用cgroup統計子系統(Simple CPU accounting cgroup subsystem (CGROUP_CPUACCT))（Cgroup子系統的簡單CPU統計）會生成一個資源控制器來監控在一個cgroup組內的獨立任務的CPU使用情況。我選擇了"no"。

資源計數器(Resource counters (RESOURCE_COUNTERS))使控制器的獨立資源統計功能能夠統計cgroup。我選擇了"no"。

下一個問題(Enable perf_event per-cpu per-container group (cgroup) monitoring (CGROUP_PERF))（啟用每個CPU、每個容器組的pref_event監控）允許開發者擴展每個CPU的模式，使它可以只監控運行在特定CPU上的一個特別的cgroup組的線程。

下一章節是"Group CPU Scheduler"（CPU分組調度器）。前兩個已經回答的問題包括：

Group CPU scheduler (CGROUPSCHED)（CPU分組調度器） Group scheduling for SCHEDOTHER (FAIRGROUPSCHED)（SCHED_OTHER分組調度）

第一個已回答的問題(CPU bandwidth provisioning for FAIR_GROUP_SCHED (CFS_BANDWIDTH))（CPU帶寬分配）詢問的是內核是否允許用戶設置在公平組調度器內執行的任務的CPU帶寬限制。沒有限制的組會被認為不受約束，並會沒有限制地運行。

注意：並不是所有內核選項都在這裡。我這裡提到的組只是為了便於閱讀，並挑出那些新的和大的部分。並不需要了解所有的分組。分組有助於使用圖形工具配置內核，這樣開發者可以在搜索特定的設置時，直接通過分組菜單找到。

開發者可以通過回答"Group scheduling for SCHED_RR/FIFO (RT_GROUP_SCHED)"（SCHED_RR/FIFO分組調度）這個問題為"yes"來讓用戶可以分配CPU帶寬到任務組中。

下一個問題是"Block IO controller (BLK_CGROUP)"（阻塞IO控制器）。任務組可以被識別，並且它們的磁碟帶寬是由使用塊IO控制器實現的CFQ IO調度器分配的。BIO在塊級的限制邏輯使用塊IO控制器來提供設備上的IO速率上限。

這裡有一個調試問題(Enable Block IO controller debugging (DEBUGBLKCGROUP) [N/y/?])（啟用阻塞IO控制器的調試）詢問是否啟用塊IO控制器的調試。為了製作一個精簡的內核，最好禁用這個特性。

為了啟用內核中的檢查點和還原特性。這個問題「Checkpoint/restore support (CHECKPOINT_RESTORE)」（檢查點及還原支持）可以選擇「yes」，不過為了更低的負載這裡我選擇了「n」。啟用這個特性會增加輔助的進程式控制制代碼來設置進程的代碼段、數據段和堆的大小，並增加了一些額外的程序入口。

下面我們就要配置命名空間的支持了。命名空間是一組標識符的容器。比如，/usr/lib/python3/dist-packages/re.py就是一個標識符，/usr/lib/python3/dist-packages/就是一個命名空間。而re.py是這個命名空間下的本地名稱。

第一個命名空間問題(Namespaces support (NAMESPACES))詢問的是是否啟用命名空間。這允許可以使用相同的PID但在不同的命名空間內(譯註：原文為" This will allow the same PIDs (Process ID) to be used but indifferent namespaces",這裡indiffernt根據上下文應該是少了空格)，否則PID永遠不會重複。

下一個問題(UTS namespace (UTS_NS))詢問是否可以讓UTS命名空間內的任務可以在uname()系統調用中看到不同的信息。uname()系統調用提供查看機器和操作系統的信息。

啟用IPC命名空間(IPC namespace (IPC_NS))將允許在這個命名空間內的任務與其他命名空間內相對應IPC ID的對象協同工作。

PID命名空間(PID Namespaces (PID_NS))就是進程ID命名空間。這可以使不同的進程在不同的PID命名空間使用相同的PID。這是一個容器的構建塊。

接下來，啟用網路命名空間(Network namespace (NET_NS))可以使用戶創建一個擁有多個實例的網路棧。

當啟用後,自動進程分組調度(SCHED_AUTOGROUP)會填充並創建任務組來優化桌面程序的調度。它將把佔用大量資源的應用程序放在它們自己的任務組，這有助於性能提升。

這裡是一個調試特性，除非你有特別的需求否則應該禁用它。這個問題(Enable deprecated sysfs features to support old userspace tools (SYSFS_DEPRECATED))（啟用不推薦的sysfs功能來支持舊式的用戶空間工具）詢問是否啟用sysfs，這是調試內核時用的虛擬文件系統。

接下來，因為當前的配置需要它，所以"Kernel->user space relay support (formerly relayfs) (RELAY)"（內核->用戶空間的中繼支持，即relayfs）已經被設成"yes"了。最好啟用initrd支持(Initial RAM filesystem and RAM disk (initramfs/initrd) support (BLK_DEV_INITRD))（初始化內存文件系統和內存檔(initramfs/initrd)）。

用戶會被問及哪裡放置initramfs源文件。如果沒有需要，請留空。

接下來,開發人員會被詢問關於初始虛擬磁碟(Linux的內核映像文件)所支持的壓縮格式。你可以啟用所有支持的壓縮格式。

• Support initial ramdisks compressed using gzip (RD_GZIP)
• Support initial ramdisks compressed using bzip2 (RD_BZIP2)
• Support initial ramdisks compressed using LZMA (RD_LZMA)
• Support initial ramdisks compressed using XZ (RD_XZ)
• Support initial ramdisks compressed using LZO (RD_LZO)

這裡設置了內核的編譯內核編譯選項(Optimize for size (CC_OPTIMIZE_FOR_SIZE))（優化大小）。開發者可以讓編譯器在編譯時優化代碼。我選擇了"yes"。

用戶想要配置更多的內核特性，那麼下個問題就回答"yes"(Configure standard kernel features (expert users) (EXPERT))（配置標準內核特性（專家級用戶））。

要啟用過時的16位UID系統調用封裝器，這個問題設成"yes"(Enable 16-bit UID system calls (UID16))。系統調用就會使用16位UID。

推薦啟用"sysctl syscall"(Sysctl syscall support (SYSCTL_SYSCALL))支持。這使/proc/sys成為二進位路徑的介面。

接下來的兩個問題已經被預先回答了"yes",它們是"Load all symbols for debugging/ksymoops (KALLSYMS)"（載入所以的調試符號）和"「Include all symbols in kallsyms (KALLSYMS_ALL)"（包括所有的kallsyms符號）。這些都是啟用調試標誌。

下一步，開發者應該啟用printk支持( (Enable support for printk (PRINTK)))，這會輸出內核消息到內核日誌中。這在內核出錯時是很重要的。編譯一個"啞巴"內核並不是一個好主意。然而，如果我們啟用了這個支持，就會被一些開發者看到這些出錯，要麼就不要啟用。

除非有必要，開發者可以禁用bug支持(BUG() support (BUG))。禁用這項將會不支持WARN信息和BUG信息。這會減小內核的體積。

via: http://www.linux.org/threads/the-linux-kernel-configuring-the-kernel-part-2.4318/

譯者：geekpi 校對：wxy

本文由 LCTT 原創翻譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive