mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
Merge pull request #313 from geekpi/master
[Translated] 06 The Linux Kernel--Configuring the Kernel Part 2
This commit is contained in:
vito-L
commit
f925790555
@ -1,138 +0,0 @@
|
||||
Translating----------------------geekpi
|
||||
|
||||
06 The Linux Kernel: Configuring the Kernel Part 2
|
||||
================================================================================
|
||||
|
||||
|
||||
The next portion of the kernel that is configured is the IRQ subsystem. An Interrupt ReQuest (or IRQ) is a signal from the hardware to the processor to temporarily stop a running program and allow a special program to execute in its place.
|
||||
|
||||
The first question belonging to this category of kernel features (Expose hardware/virtual IRQ mapping via debugfs (IRQ_DOMAIN_DEBUG)) asks if the IRQ numbers of the hardware and the respective can be mapped using a virtual debugging filesystem. This is for debugging purposes. Most users will not need this, so I will select “no”.
|
||||
|
||||
The next heading displays “Timers subsystem”. The first question pertaining to the timers subsystem is “Tickless System (Dynamic Ticks) (NO_HZ)”. Selecting “yes” (which I did) will enable a tickless system. This means that the timer interrupts will be used as needed. Timer interrupts allow tasks to be executed at particular timed intervals. The next question (High Resolution Timer Support (HIGH_RES_TIMERS)) asks if high resolution timer support can be enabled. Not all hardware supports this. Generally, if the hardware is slow or old, then select “no”, else select “yes” as I did.
|
||||
|
||||
The next heading - “CPU/Task time and stats accounting” - pertains to keeping track of processes. The first question looks like this
|
||||
|
||||
Cputime accounting
|
||||
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)
|
||||
|
||||
TICK_CPU_ACCOUNTING checks /proc/stat on every CPU tick. This is the default choice. This accounting method is very simple.
|
||||
|
||||
NOTE: A CPU tick is an abstract way of measuring time by the CPU. Every processor, operating system, and installation is different. For example, a more powerful processor will have more CPU ticks than an old processor. If you install a Linux system and then reinstall from the same disk, you may have a faster or slower CPU tick time (at least that is what some computer techs say). Generally, a larger clock speed means more CPU ticks.
|
||||
|
||||
If VIRT_CPU_ACCOUNTING_GEN is enabled, task and CPU time accounting will be implemented by watching kernel-user boundaries. This choice comes with a price – extra overhead.
|
||||
|
||||
The IRQ_TIME_ACCOUNTING accounting method works by checking a time-stamp between IRQ states. The performance cost is small.
|
||||
|
||||
I chose “1” and was then asked about BSD Accounting “BSD Process Accounting (BSD_PROCESS_ACCT)”. This kernel feature logs a variety of information for each process that closes. For a smaller and faster kernel, I will choose “no”.
|
||||
|
||||
The next set of questions looks like the following.
|
||||
|
||||
Export task/process statistics through netlink (TASKSTATS)
|
||||
Enable per-task delay accounting (TASK_DELAY_ACCT)
|
||||
Enable extended accounting over taskstats (TASK_XACCT)
|
||||
|
||||
TASKSTATS gives the kernel the ability to export process statistics through a netlink socket. Netlink sockets are a form of IPC between the kernel and user space processes. TASK_DELAY_ACCT watches the processes and the delays concerning the access of resources. For example, TASK_DELAY_ACCT would see that process-X is waiting for some CPU time. The process is then given some CPU time if TASK_DELAY_ACCT notices that the process waits too long. TASK_XACCT collects extra accounting data. I will disable this for less kernel overhead.
|
||||
|
||||
Now, the next category is displayed – RCU Subsystem. The Read-Copy-Update subsystem is a low-overhead syncing mechanism that allows programs to view files that are in the process of being modified/updated. The configuration tool answered the first question.
|
||||
|
||||
RCU Implementation
|
||||
> 1. Tree-based hierarchical RCU (TREE_RCU)
|
||||
choice[1]: 1
|
||||
|
||||
This is to select the type of RCU. Besides TREE_RCU, there is classic RCU (the older implementation). The next question (Consider userspace as in RCU extended quiescent state (RCU_USER_QS) [N/y/?]) asks if RCU can be put in a special state when the CPU runs in userspace. This feature is usually disabled because this adds too much overhead. After this question is another RCU question (Tree-based hierarchical RCU fanout value (RCU_FANOUT) [64]) asking for a fanout value. The next question (Tree-based hierarchical RCU leaf-level fanout value (RCU_FANOUT_LEAF) [16]) is another fanout value question except this one deals with the leaf-level. Yet again, another RCU question (Disable tree-based hierarchical RCU auto-balancing (RCU_FANOUT_EXACT) [N/y/?]) asking if the RCU auto-balancing can be disabled.
|
||||
|
||||
Next, the configuration script asks this question “Accelerate last non-dyntick-idle CPU's grace periods (RCU_FAST_NO_HZ)”. After that, “Offload RCU callback processing from boot-selected CPUs (RCU_NOCB_CPU)” is displayed.
|
||||
|
||||
This next question is very important (Kernel .config support (IKCONFIG)). The developer has the choice of saving the settings made in this configuration tool into a file. This file can be placed in the kernel, in a module, or not saved at all. This file can be used by other developers that want to compile a kernel exactly as someone else. This file can also help developers recompile a kernel using a newer compiler. For illustration, a developer configures and compiles a kernel. The compiler has some bugs, but the developer still needs a kernel with these settings. Thankfully, the developer can upgrade their compiler and use the settings file to save them time from configuring the kernel again. The developer could also save the source code and config file and compile the kernel on another computer. As for another purpose, the developer can load this file and tweak the settings as needed. I chose to save the config file in a module. “Enable access to .config through /proc/config.gz (IKCONFIG_PROC)” asks if this file is accessible. I chose yes.
|
||||
|
||||
The next question asks how large to make the kernel log buffers (Kernel log buffer size (16 => 64KB, 17 => 128KB) (LOG_BUF_SHIFT) [17]). Smaller buffers indicate logs are not kept as long as logs set to higher buffers. This choice depends on how long the developer wishes the logs to last. I chose “12”.
|
||||
|
||||
Again, another question appears. This one asks about enabling NUMA (Non-Uniform Memory Access) aware memory/task placement (Automatically enable NUMA aware memory/task placement (NUMA_BALANCING_DEFAULT_ENABLED)). If set and if the computer is a NUMA machine, then NUMA balancing will be enabled. Under NUMA, a processor can access its own local memory faster than non-local memory (memory local to another processor or memory shared between processors). If the above is enabled (I enabled it), then it would be best to answer yes to “Memory placement aware NUMA scheduler (NUMA_BALANCING)”. This is the NUMA scheduler.
|
||||
|
||||
Under the new heading “Control Group support”, the choice “Control Group support (CGROUPS)” is automatically answered “yes” due to previous choices.
|
||||
|
||||
The following setting (Example debug cgroup subsystem (CGROUP_DEBUG)) is for enabling a simple cgroup subsystem for debugging the cgroups framework. The next choice (Freezer cgroup subsystem (CGROUP_FREEZER)) allows programmers to allow the ability to freeze and unfreeze tasks in a cgroup.
|
||||
|
||||
NOTE: A cgroup is a group of processes.
|
||||
|
||||
Next, we are asked “Device controller for cgroups (CGROUP_DEVICE)”. Cgroups (Control Groups) is a feature used to control resource usage. Answering “yes” will allow cgroup whitelists for the devices cgroups can open or mknod (system call for creating a file system node).
|
||||
|
||||
The next question (Cpuset support (CPUSETS)) asks if it can allow the creation and management of CPUSETS. This would allow administrators to dynamically partition sets of Memory Nodes and CPUs on a system and assign tasks to run on those sets. This is usually used on SMP and NUMA systems. I answered “no” on this question.
|
||||
|
||||
NOTE: Remember, if I do not specify what I chose, then I chose the default.
|
||||
|
||||
Enabling a cgroup accounting subsystem (Simple CPU accounting cgroup subsystem (CGROUP_CPUACCT)) makes a resource controller for monitoring the CPU usage of individual tasks in a cgroup. I chose “no”.
|
||||
|
||||
Resource counters (Resource counters (RESOURCE_COUNTERS)) enables controller independent resource accounting infrastructure that works with cgroups. I chose “no”.
|
||||
|
||||
The next question (Enable perf_event per-cpu per-container group (cgroup) monitoring (CGROUP_PERF)) allows developers to extend the per-cpu mode to make it only monitor threads of a particular cgroup on a specific CPU. I chose “no”.
|
||||
|
||||
The next section is “Group CPU Scheduler”. The first two pre-answered questions include
|
||||
|
||||
Group CPU scheduler (CGROUP_SCHED)
|
||||
Group scheduling for SCHED_OTHER (FAIR_GROUP_SCHED)
|
||||
|
||||
The first answerable question (CPU bandwidth provisioning for FAIR_GROUP_SCHED (CFS_BANDWIDTH)) asks if the kernel should allow users to set CPU bandwidth limits for tasks executing in the fair group scheduler. Groups with no limit set are considered to be unconstrained and will run with no restriction.
|
||||
|
||||
NOTE: Not all of the kernel options are in groups. I mention groups only for the ease of reading and to indicate a new, large topic. It is not important to know the groups. This grouping system is helpful when configuring the kernel using the graphical tools. Then, developers can look through the menus that are grouped when searching for a particular setting.
|
||||
|
||||
Developers can enable users to allocate CPU bandwidth to task groups by answering yes to “Group scheduling for SCHED_RR/FIFO (RT_GROUP_SCHED)”.
|
||||
|
||||
The next question is “Block IO controller (BLK_CGROUP)”. Task groups are recognized and their disk bandwidth is allocated by the CFQ IO scheduler which uses the block IO controller to do so. The BIO throttling logic in the block layer uses a block IO controller to provide upper limit in IO rates on a device.
|
||||
|
||||
Here is a debugging question (Enable Block IO controller debugging (DEBUG_BLK_CGROUP) [N/y/?]) that is asking to enable debugging for block IO controllers. To make a streamlined kernel, it is best to disable this feature.
|
||||
|
||||
To enable checkpoint and restore features in the kernel answer yes to “Checkpoint/restore support (CHECKPOINT_RESTORE)”. I chose no for less overhead. Enabling this feature would add auxiliary prctl codes to setup process text, data and heap segment sizes, and a few additional proc entries.
|
||||
|
||||
Next, we will configure namespace support. A namespace is a container for a group of identifiers. For illustration, /usr/lib/python3/dist-packages/re.py is an identifier, /usr/lib/python3/dist-packages/ is the namespace, and re.py is the localname in the namespace.
|
||||
|
||||
The first namespace question (Namespaces support (NAMESPACES)) asks if namespaces can be enabled. This will allow the same PIDs (Process ID) to be used but indifferent namespaces. Otherwise, PIDs can never be duplicated.
|
||||
|
||||
The next question (UTS namespace (UTS_NS)) asks to enable the ability for tasks in the UTS namespace to see different information in the uname() system call. The uname() system call provides information about the machine and operating system.
|
||||
|
||||
Enabling the IPC namespace (IPC namespace (IPC_NS)) will allow tasks in this namespace to work with IPC IDs which correspond to different IPC objects in different namespaces.
|
||||
|
||||
PID Namespaces (PID Namespaces (PID_NS)) are process ID namespaces. This allows multiple processes, each in different PID namespaces, to use the same PID. This is a building block of containers.
|
||||
|
||||
Next, enabling network namespaces (Network namespace (NET_NS)) will allow users to make a network stack appear to have multiple instances.
|
||||
|
||||
When enabled, Automatic process group scheduling (SCHED_AUTOGROUP) populates and creates task groups to optimize the scheduler for desktop workloads. This will put applications that take up a lot of resources in their own task group. This helps performance.
|
||||
|
||||
Here is a debugging feature that should be disabled unless it is specifically needed. This question (Enable deprecated sysfs features to support old userspace tools (SYSFS_DEPRECATED)) asks if sysfs should be enabled. This is a virtual filesystem for debugging the kernel.
|
||||
|
||||
Next, the question “Kernel->user space relay support (formerly relayfs) (RELAY)” is answered “yes” because it is needed with the current configuration. It is best to allow initrd support (Initial RAM filesystem and RAM disk (initramfs/initrd) support (BLK_DEV_INITRD)).
|
||||
|
||||
The user is asked where to put the initramfs source files. If none are needed, then leave this blank.
|
||||
|
||||
Next, the developer is asked about the supported compression format for the initial ramdisks (Linux image files for the kernel). It is fine to enable support for all of the compression formats.
|
||||
|
||||
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)
|
||||
|
||||
Here, the compiling options for the kernel are set (Optimize for size (CC_OPTIMIZE_FOR_SIZE)). The developer can have the compiler optimize the code when compiling. I chose “yes”.
|
||||
|
||||
For users wanting to configure more kernel features, then they can answer “yes” for this next question (Configure standard kernel features (expert users) (EXPERT)).
|
||||
|
||||
|
||||
To enable legacy 16-bit UID syscall wrappers, answer yes to this question (Enable 16-bit UID system calls (UID16)). These system calls use 16-bit user IDs.
|
||||
|
||||
It is recommended to enable sysctl syscall support (Sysctl syscall support (SYSCTL_SYSCALL)). This allows /proc/sys to be the interface for binary paths.
|
||||
|
||||
The next two questions about debugging have been pre-answered “yes” - “Load all symbols for debugging/ksymoops (KALLSYMS)” and “Include all symbols in kallsyms (KALLSYMS_ALL)”. These enable debugging symbols.
|
||||
|
||||
Next, developers should enable printk support (Enable support for printk (PRINTK)). This prints kernel messages to the kernel log. This is important if something goes wrong with the kernel. Having a mute kernel is not a good idea. However, some developer saw a purpose for it if we have a choice. Otherwise, we would not have a choice.
|
||||
|
||||
Unless needed, developers can disable bug support (BUG() support (BUG)). Disabling this will remove support for WARN and BUG messages. This reduces the kernel's size.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.linux.org/threads/the-linux-kernel-configuring-the-kernel-part-2.4318/
|
||||
|
||||
译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
2
sources/The Linux Kernel/07 The Linux Kernel--Configuring the Kernel Part 3.md
Normal file → Executable file
2
sources/The Linux Kernel/07 The Linux Kernel--Configuring the Kernel Part 3.md
Normal file → Executable file
@ -1,3 +1,5 @@
|
||||
Translating-------------------geekpi
|
||||
|
||||
07 The Linux Kernel: Configuring the Kernel Part 3
|
||||
================================================================================
|
||||
|
||||
|
||||
@ -0,0 +1,136 @@
|
||||
06 Linux 内核: 内核配置(Part 2)
|
||||
================================================================================
|
||||
|
||||
|
||||
第二部分我们讲配置内核IRQ子系统。中断请求(IRQ)硬件发给处理器的一个信号，它暂时停止一个正在运行的程序并允许一个特殊的程序在它的位置上运行。
|
||||
|
||||
这个目录中的第一个问题属于内核特性(Expose hardware/virtual IRQ mapping via debugfs (IRQ_DOMAIN_DEBUG))询问的是硬件的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",这个是关于进程的追踪。第一个问题看上去像这样
|
||||
|
||||
Cputime accounting
|
||||
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)
|
||||
|
||||
TICK_CPU_ACCOUNTING会在每个CPU滴答检测/proc/stat。这是默认的选项，这个统计方法非常简单
|
||||
|
||||
注意：CPU滴答是抽象测量CPU时间的方式。每个处理器，操作系统和安装方式都不同，比如说，一个更强大的处理器会比老的处理器拥有更多的CPU滴答。如果你安装了一个Linux系统接着在同一块磁盘上重新安装了它。你可能会得到一个更快或更慢的CPU滴答时间(至少一些计算机技术书上这么说)。通常来讲，一个更快的时钟速度意味着更多的时间滴答。
|
||||
|
||||
如果启用了VIRT_CPU_ACCOUNTING_GEN，任务和CPU时间统计将由监视内核-用户边界实现。这个选择的代价是会增加额外的开销。
|
||||
|
||||
IRQ_TIME_ACCOUNTING统计方式通过检测IRQ状态间的时间戳工作，这个性能开销很小。
|
||||
|
||||
我选择了"1"并被询问有关BSD统计"BSD Process Accounting (BSD_PROCESS_ACCT)"的问题.这个内核特性会记录每个进程不同的关闭信息。为了得到一个更小和更快的内核，我选择了"no".
|
||||
|
||||
下一组问题看上去就像下面这样。
|
||||
|
||||
Export task/process statistics through netlink (TASKSTATS)
|
||||
Enable per-task delay accounting (TASK_DELAY_ACCT)
|
||||
Enable extended accounting over taskstats (TASK_XACCT)
|
||||
|
||||
TASKSTATS使内核可以通过网络套接字导出进程统计。网络套接字是内核和用户空间进程间IPC通信的一种形式。TASK_DELAY_ACCT监视进程并延迟关心资源的访问。比如，TASK_DELAY_ACCT可以看到X进程正在为了CPU时间而等待。这个进程接着就会被给予一些CPU时间如果TASK_DELAY_ACCT观察到进程已经等待了太长时间。TASK_XACCT收集额外的统计数据。为了更小的内核负载我会禁用这个。
|
||||
|
||||
现在接下来的目录就会显示出来-RCU子系统。读-拷贝修改子系统是一种低负载的同步机制，它允许程序查看到正在被修改/更新的文件。配置工具已经回答了第一个问题。
|
||||
|
||||
RCU Implementation
|
||||
> 1. Tree-based hierarchical RCU (TREE_RCU)
|
||||
choice[1]: 1
|
||||
|
||||
这是RCU类型的选择。除了TREE_RCU，还有classic RCU(更老的实现)。下一个问题(Consider userspace as in RCU extended quiescent state (RCU_USER_QS) [N/y/?])问的是RCU是否可以在CPU运行在用户空间时设置一个特殊的状态。这个选项通常被禁用因为这回增加太多消耗。下面是另一个RCU问题(Tree-based hierarchical RCU fanout value (RCU_FANOUT) [64]),问的是关于换出值。下一个问题(ree-based hierarchical RCU leaf-level fanout value (RCU_FANOUT_LEAF) [16]),是另外一个关于转出值的问题但它只处理叶级。还有另外一个RCU问题(Disable tree-based hierarchical RCU auto-balancing (RCU_FANOUT_EXACT) [N/y/?]),询问是否禁用RCU自动平衡。
|
||||
|
||||
接下来，配置脚本将会询问"Accelerate last non-dyntick-idle CPU's grace periods (RCU_FAST_NO_HZ)"。在这之后会显示"Offload RCU callback processing from boot-selected CPUs (RCU_NOCB_CPU)";
|
||||
|
||||
下一个问题非常重要(Kernel .config support (IKCONFIG))。开发人员可以选择保存由该配置工具生成的设置到一个文件中。这个文件可以放在内核中,也可在一个模块中,或者完全不保存。这个文件安可以被想要编译一个完全跟某人相同内核的开发者使用。这个文件还可以帮助开发人员使用一个更新的编译器重新编译一个内核。举例来说,开发人员配置并编译了一个内核。然而编译器有一些bug,但开发人员仍然需要使用这些设置的内核。值得庆幸的是,开发人员可以升级他们的编译器并使用设置文件来节省他们重新配置内核的时间。开发人员也可以在另一台计算机上保存源代码和配置文件并编译内核。至于另一个目的,开发人员可以加载该文件,并根据需要调整设置。我选择保存配置文件在一个模块中。这个问题 "Enable access to .config through /proc/config.gz (IKCONFIG_PROC)"询问这个文件是否是可以访问的。我选择了"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下，处理器可以比非本地内存(在另一台处理器上的内存或者处理器之间的共享内存)更快地访问它的本地内存。如果上面启用了(我启用了)，那么最好对这个问题"Memory placement aware NUMA scheduler (NUMA_BALANCING)"回答"yes"。这是一个NUMA调度器。
|
||||
|
||||
在新的标题"Control Group support"下，因为先前的选择，"Control Group support (CGROUPS)"被自动地回答了"yes"。
|
||||
|
||||
以下设定(Example debug cgroup subsystem (CGROUP_DEBUG))是启动用于调式cgroup框架的一个简单的cgroup子系统。下一个选项(Freezer cgroup subsystem (CGROUP_FREEZER))可以让程序员可以冻结或者解冻cgroup内的任务。
|
||||
|
||||
注意：cgroup是一个进程组。
|
||||
|
||||
Next, we are asked “Device controller for cgroups (CGROUP_DEVICE)”. Cgroups (Control Groups) is a feature used to control resource usage. Answering “yes” will allow cgroup whitelists for the devices cgroups can open or mknod (system call for creating a file system node).
|
||||
下面我们要求回答"Device controller for cgroups (CGROUP_DEVICE)"。cgroup(控制组)是一种用来控制资源使用的特性。回答"yes"可以允许设备cgroup的白名单可以使用open和mknod系统调用(用来创建文件系统节点的系统调用)。
|
||||
|
||||
下一个问题(Cpuset support (CPUSETS))询问的是内核是否可以创建和管理CPUSETS。这允许管理员可以在一个系统上动态分配各组内存节点并分配任务在这些内存上运行。这通常用于SMP和NUMA系统中。我这个问题回答的是"no"。
|
||||
|
||||
注意：请记住，如果我没有指定我选的是什么，那么我选的就是默认选项。
|
||||
|
||||
启用cgroup统计子系统(Simple CPU accounting cgroup subsystem (CGROUP_CPUACCT))会生成一个资源控制器来监控在一个cgroup组内的独立任务的CPU使用情况。我选择了"no"。
|
||||
|
||||
资源计数器(Resource counters (RESOURCE_COUNTERS))使控制器独立资源能够统计工作在cgroup上的设备。我选择了"no"。
|
||||
|
||||
下一个问题(Enable perf_event per-cpu per-container group (cgroup) monitoring (CGROUP_PERF))允许开发者扩展扩展每个CPU的模式，使它可以只监控运行在特定CPU上的一个特别的cgroup组的线程。
|
||||
|
||||
下一章节是"Group CPU Scheduler"。前两个已经回答的问题包括：
|
||||
|
||||
Group CPU scheduler (CGROUP_SCHED)
|
||||
Group scheduling for SCHED_OTHER (FAIR_GROUP_SCHED)
|
||||
|
||||
第一个已回答的问题(CPU bandwidth provisioning for FAIR_GROUP_SCHED (CFS_BANDWIDTH))询问的是内核是否允许用户设置在公平组调度器内执行的任务的CPU带宽限制。没有限制的组会被认为不受约束并会没有限制地运行。
|
||||
|
||||
注意：并不是所有内核选项都在这个组里。我这里提到的组只是为了阅读舒适并指出这是一个新的，大的主题。了解所有组并不重要。当使用图形工具配置内核时，分组系统是有帮助的。那么开发者可以在搜索特定的设置时直接浏览分组后的菜单就可以了
|
||||
|
||||
开发者可以通过回答"Group scheduling for SCHED_RR/FIFO (RT_GROUP_SCHED)"这个问题为"是"使用户可以分配CPU带宽到任务组中。
|
||||
|
||||
下一个问题是"Block IO controller (BLK_CGROUP)"。这样任务组就可以被识别并且它们的磁盘带宽是由使用块IO控制器实现的CFQ IO调度器分配的。BIO在块层的限制逻辑使用块IO控制器来提供设备上的IO速率上限。
|
||||
|
||||
这里有一个调试问题(Enable Block IO controller debugging (DEBUG_BLK_CGROUP) [N/y/?])询问的是是否启用块IO控制器的调试。为了制作一个精简的内核，做好禁用这个特性。
|
||||
|
||||
为了启用内核中的检查点和还原特性。这个问题“Checkpoint/restore support (CHECKPOINT_RESTORE)”我们回答是。为了更低的负载这里我选择了否。启用这个特性会正经啊辅助的进程控制代码来设置进程的代码段，数据段和堆的大小。并增加了一些额外的程序入口。
|
||||
|
||||
下面我们就要配置命名空间的支持了。命名空间是一组标识符的容器。比如，/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。这是调式内核时用的虚拟文件系统。
|
||||
|
||||
接下来，因为当前的配置需要它，所以"Kernel->user space relay support (formerly relayfs) (RELAY)"已经被设成"yes"了。最好启用initrd(初始化内存文件系统和内存盘(initramfs/initrd))支持(BLK_DEV_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)"。这些都是启用调试标志。
|
||||
|
||||
下一步，开发者应该启用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](https://github.com/geekpi) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
Loading…
Reference in New Issue
Block a user