心情大好，昨晚我们实验室老大和我们聊了好久，作为已经在实验室待了快两年的大三工科男来说，老师让我们不要成为那种技术狗，代码工，说多了都是泪啊，，不过我们的激情依旧不变，老师帮我们组好了队伍，着手参加明年的全国大赛，说起来我们学校历史上也就又一次拿国一的，去了一次人民大会堂领奖，可以说老大是对我们寄予厚望，以后我会专攻仪器仪表类的题目，激情不灭，梦想不息，不过最近一段时间还是会继续更新Linux内核，总之，继续加油~
　　Linux2.6版本中的内核引入了一个全新的调度程序，称为O(1)调度程序，进程在被初始化并放到运行队列后，在某个时刻应该获得对CPU的访问，它负责把CPU的控制权传递到不同进程的两个函数schedule()和schedule_tick()中。下图是随着时间推移，CPU是如何在不同进程之间传递的，至于细节这里不多阐释，大家看待就可以理解的啦~
　　下面开始介绍一下上下文切换，在操作系统中，CPU切换到另一个进程需要保存当前进程的状态并恢复另一个进程的状态：当前运行任务转为就绪（或者挂起、删除）状态，另一个被选定的就绪任务成为当前任务。上下文切换包括保存当前任务的运行环境，恢复将要运行任务的运行环境。
&如何获得上下文切换的次数？
　　vmstat直接运行即可，在最后几列，有CPU的context switch次数。 这个是系统层面的，加入想看特定进程的情况，可以使用pidstat。
1 $ vmstat 1 100
2 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
cs us sy id wa st
88 233484 288756 1784744
88 233236 288756 1784752
0 6202 7880
88 233360 288756 1784800
112 6277 7612
88 232864 288756 1784804
644 5747 6593
执行pidstat，将输出系统启动后所有活动进程的cpu统计信息：&&
1 linux:~ # pidstat
2 Linux 2.6.32.12-0.7-default (linux)
4 11:37:19
%usr %system
6 11:37:19
7 11:37:19
8 11:37:19: pidstat获取信息时间点
9 PID: 进程pid
10 %usr: 进程在用户态运行所占cpu时间比率
11 %system: 进程在内核态运行所占cpu时间比率
12 %CPU: 进程运行所占cpu时间比率
13 CPU: 指示进程在哪个核运行
14 Command: 拉起进程对应的命令
15 备注:执行pidstat默认输出信息为系统启动后到执行时间点的统计信息，因而即使当前某进程的cpu占用率很高
上下文切换的性能消耗在哪里呢？
&&&&&&&&context switch过高，会导致CPU像个搬运工，频繁在寄存器和运行队列直接奔波& ，更多的时间花在了线程切换，而不是真正工作的线程上。直接的消耗包括CPU寄存器需要保存和加载，系统调度器的代码需要执行。间接消耗在于多核cache之间的共享数据。&& &
引起上下文切换的原因有哪些？
对于抢占式操作系统而言，&大体有几种：
当前任务的时间片用完之后，系统CPU正常调度下一个任务；
当前任务碰到IO阻塞，调度线程将挂起此任务，继续下一个任务；
多个任务抢占锁资源，当前任务没有抢到，被调度器挂起，继续下一个任务；
用户代码挂起当前任务，让出CPU时间；
硬件中断；& & & &
如何测试上下文切换的时间消耗？
　　这里我再网上查找到了一个程序，代码不长，切换一个 & 差不多就是 &20个微秒吧，这个程序望大神指教
1 #include &stdio.h&
2 #include &unistd.h&
3 #include &sys/time.h&
4 #include&pthread.h&
6 int pipes[20][3];
7 char buffer[10];
8 int running = 1;
10 void inti()
int i =20;
while(i--)
if(pipe(pipes[i])&0)
pipes[i][2] =
21 void distroy()
int i =20;
while(i--)
close(pipes[i][0]);
close(pipes[i][1]);
31 double self_test()
int i =20000;
struct timeval start,
gettimeofday(&start, NULL);
while(i--)
if(write(pipes[0][1],buffer,10)==-1)
read(pipes[0][0],buffer,10);
gettimeofday(&end, NULL);
return (double)(1000000*(end.tv_sec-start.tv_sec)+ end.tv_usec-start.tv_usec)/20000;
46 void *_test(void *arg)
int pos = ((int *)arg)[2];
int in = pipes[pos][0];
int to = pipes[(pos + 1)%20][1];
while(running)
read(in,buffer,10);
if(write(to,buffer,10)==-1)
59 double threading_test()
int i = 20;
struct timeval start,
while(--i)
pthread_create(&tid,NULL,_test,(void *)pipes[i]);
i = 10000;
gettimeofday(&start, NULL);
while(i--)
if(write(pipes[1][1],buffer,10)==-1)
read(pipes[0][0],buffer,10);
gettimeofday(&end, NULL);
running = 0;
if(write(pipes[1][1],buffer,10)==-1)
return (double)(1000000*(end.tv_sec-start.tv_sec)+ end.tv_usec-start.tv_usec)/10000/20;
84 int main()
printf("%6.6f\n",self_test());
printf("%6.6f\n",threading_test());
distroy();
　　总而言之，我们可以认为，这最多只能是依赖于底层操作系统的近似计算。 一个近似的解法是记录一个进程结束时的时间戳，另一个进程开始的时间戳及排除等待时间。如果所有进程总共用时为T，那么总的上下文切换时间为： T & (所有进程的等待时间和执行时间)
　　接下来来述说抢占，抢占是一个进程到另一个进程的切换，那么Linux是如何决定在何时进行切换的呢？下面我们一次来介绍这三种抢占方式。
显式内核抢占：
　　最容易的就是这个抢占啦，它发生在内核代码调用schedule(可以直接调用或者阻塞调用)时候的内核空间中。当这种方式抢占时，例如在wait_queue等待队列中设备驱动程序在等候时，控制权被简单地传递到调度程序，从而新的进程被选中执行。
隐式用户抢占：
　　当内核处理完内核空间的进程并准备把控制权传递到用户空间的进程时，它首先查看应该把控制权传递到哪一个用户空间的进程上，这个进程也行不是传递其控制权到内核的那个用户空间进程。系统中中的每一个进程有一个&必须重新调度&，在进程应该被重新调度的任何时候设置它。代码可以在include/linux/sched.h中查看~
static inline void set_tsk_need_resched(struct task_struct *tsk)
set_tsk_thread_flag(tsk,TIF_NEED_RESCHED);
static inline void clear_tsk_need_resched(struct task_struct *tsk)
clear_tsk_thread_flag(tsk,TIF_NEED_RESCHED);
//set_tsk_need_resched和clear_tsk_need_resched是两个接口，用于设置体系结构特有的TIF_NEED_RESCHED标志
stactic inline int need_resched(void)
return unlikely(test_thread_flag(TIF_NEED_RESCHED));
}//need_resched测试当前线程的标志，看看TIF_NEED_RESCHED是否被设置
隐式内核抢占：
　　隐式内核抢占有两种可能性：内核代码出自使抢占禁止的代码块，或者处理正在从中断返回到内核代码时，如果控制权正在从一个中断返回到内核空间，该中断调用schedule()，一个新的 进程以刚才描述的同一种方式被选中，如果内核代码出自禁止抢占的代码块，激活抢占 的操作可能引起当前进程被抢占(代码在include/linux/preempt.h中查看到):
#define preempt_enable() \
preempt_enable_no_resched(); \
preempt_check_resched(); \
} while(0)
　　preempt_enable()调用preempt_enable_no_resched()，它把与当前进程相关的preempt_count减1，然后调用preempt_check_resched():
#define preempt_check_resched() \
if(unlikely(test_thread_flag(TIF_NEED_RESCHED))); \
preempt_schedule(); \
} while(0)
preempt_check_resched()判断当前进程是否被标记为重新调度，如果是，它调用preempt_schedule()。　　　　当两个或者两个以上的进程请求对共享资源独自访问时候，它们需要具有这样一种条件，即它们是在给代码段中操作的唯一进程，在Linux内核锁的基本形式是自旋锁。自旋锁会因为连续循环等待或者试图两次获得锁这种方式的操作而导致死锁，所以在此之前必须初始化spin_lock_t，这个可以通过调用spin_lock_init()来完成(代码在include/linux/spinlock.h中查看)：
#define spin_lock_init(x) \
(x) -& magic = SPINLOCK_MAGIC; \
(x) -& lock = 0; \　　　　　　//设置自旋锁为"开锁"
(x) -& babble = 5; \
(x) -& module = __FILE__; \
(x) -& owner = NULL; \
(x) -& oline = 0; \
} while(0)
　　自旋锁被初始化后，可以通过调用spin_lock()或者spin_lock_irqsave()来获取，如果你使用spin_lock()那么进程可能在上锁的代码中被中断，为了在代码的临界区执行后释放，必须调用spin_unlock()或者spin_unlock_irqrestroe(),spin_unlock_irqrestroe()把中断寄存器的状态恢复成调用spin_lock_irq()时寄存器所处的状态。
　　自旋锁的缺点是它们频繁地循环直到等待锁的释放，那么对于等待时间长的代码区，最好是使用Linux kernel的另一个上锁工具：信号量。它的主要优势之一是：持有信号量的进程可以安全的阻塞，它们在SMP和中断中是保险的(代码在include/asm-i386/semaphore.h，include/asm-ppc/semaphore.h中可以查看)：
struct semaphore{
wait_queue_head_
#ifdef WAITQUEUE_DEBUG
struct semaphore{
wait_queue_head_
#ifdef WAITQUEUE_DEBUG
　　l两种体系结构的实现都提供了指向wait_queue的一个指针和一个计数，有了信号量我们能够让多于一个的进程同时进去代码的临界区，如果计数初始化为1，则表示只有一个进程能够进去代码的临界区，信号量用sema_init()来初始化，分别调用down()和up()来上锁和解锁，down()和up()函数的使用以及一些情况就不多说了看信号量的调用问题，很容易理解的。
　　好吧我真的自己不懂的越来越多了，觉得一天天的接受不了这么多，内核实在是块难啃的石头，今天这个可是查了好多一整天才写出来的，肯定有很多问题以及没有提到的地方，各路大神路过时候多指点多批评，，对一个菜鸟来说这儿不容易了，我会好好的继续看代码，看到吐的~~~
　　版权所有，转载请注明转载地址：
阅读(...) 评论()博客访问： 569923
博文数量： 46
博客积分： 958
博客等级： 准尉
技术积分： 2219
注册时间：
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： LINUX
半年来，在看ULA的过程中，针对Linux 2.6.24内核顺手做了一点注释。内容不多，个人觉得文件系统和USB这两个模块的注释还有一点意思。
所有注释都是中文，您可以与标准2.6.24内核进行比较，看看具体的注释内容。
针对2.6.24注释的时间比较短，内容不多，抱歉，请不要拍砖。更多的注释是针对linux2.6.11.12内核的，那个版本的注释算是干货。
您可以通过下载两个版本的注释。
我的邮箱是，微博号：kernel-hacker，常联系:)
谢宝友 晚于成都
阅读(3540) | 评论(4) | 转发(1) |
相关热门文章
给主人留下些什么吧！~~
什么叫ula，书名professional&linux&kernel&arch，缩写也应该是plka吧。。。
谢老师ulk&和ula哪个看起来更适合新手
：ULA是什么书?楼猪
就是深入linux内核架构 |
ULA是什么书?楼猪
请登录后评论。博客访问： 18037
博文数量： 28
注册时间：
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
发布时间： 10:24:10
序 言由于开发环境需要在linux-2.6内核上进行，于是准备对我的虚拟机上的Linux系统升级。没想到这一弄就花了两天时间(反复装系统，辛苦啊)，总算把Linux系统从2.4.20-8内核成功升级到了2.6.24内核。网上虽然有很多介.........
阅读(329) | 评论(0) | 转发(0)
给主人留下些什么吧！~~
请登录后留言。Linux-2.6.24&kernel启动过程解析(一)之引导协议及内存布局
从2011年末，我就打算把基于x86平台的linux
kernel的启动过程从上电到完全运行，系统的折腾一下。但是由于自己比较懒散，虽然零碎的看了很多论文和相关的书籍，但是对于启动过程仍然没有一个系统的认识。鉴于此，我打算从这篇博文开始，系统的梳理Linux
kernel的启动过程。特别要提到的是现在PC机的CMP（Chip Multi
Processing）也就是我们常说的片上多核心(比如Intel的i系列处理器,我的机器是i3 M 330
O(∩_∩)O~）和SMP本质上没有多大差别，因此在梳理这一部分内容时，我会加上SMP的初始化部分。如果我的分析有误，或者有任何不妥的部分，欢迎大家留言指出来，或者给我发邮件。
过于CMP和SMP，可以参考这边文章：
Chip Multi Processing aware Linux Kernel
Scheduler，author：Suresh Siddha，Venkatesh Pallipadi，Asit
第一部分：背景概述
在x86平台上，Linux采用一种相当复杂的引导过程，之所以如此一方面是由于历史演进的缘故，另一个方面也是因为早期的内核设计者(主要是Linus
Torvalds)希望内核本身具有自我引导的功能。加之PC机复杂的内存模型，以及当时在实模式运行的DOS系统成为主流操作系统，使得Linux的引导过程变得更加晦涩。
备注：我分析的Linux的启动过程主要针对Linux-2.6.24，我之所以选这个版本来分析内核，是因为从Linux
2.6.24开始，Linux
kernel的平台相关代码（arch目录）中64位的x86平台x86_64和32位平台i386都合为x86目录，并沿用到目前最新的kernel版本，这样方便于后续的学习。
截止到Linux 2.6.24内核，Linux/x86引导过程，有下面几种引导协议protocol版本：
1.& Old Kernel：仅有zImage/Image
支持（比如linux-0.11），另外一些早期的Kernels设置可能不支持命令行参数。
2.&&Protocol
2.00: (Kernel 1.3.73)，增加了bzImage和initrd支持，setup.S作为boot
loader和kernel进行通信的模块，被编译成可重定位的。但是传统的setup区域仍然被假设为可写的。
3.&&Protocol 2.01: (Kernel
Protocol 2.02: (Kernel
2.4.0-test3-pre3)，增加了新的命令行协议，降低了传统的内存上界（传统的内存上界是0xA0000，即640K），由于没有覆盖传统的setup所在的区域，这使得系统使用EBDA（Extended BIOS Data
Area）从SMM或者32位的BIOS入口点启动更为安全，另外尽管zImage已经过时，但协议2.02仍然支持。
早期的linux启动过程只是使用的0x0000（即0到1M的内存空间）中的4K到640K的区间，因此把640K称之为内存上界，4K称之为内存下界。
二. SMM(System Management Mode)IntelIntel386
SL芯OSSMM interrupt
pinSMI#APICAdvanced Programming
Interrupt ControllerSMISMMSMMContextSMMSMM
Protocol 2.03: (Kernel
2.4.18-pre1)：明确bootload可以使用initrd的高地址。
对于早期内核zImage/Image（比如Linux-0.11）如何使用这种内存布局，可以参考以前的一篇博文：&&。但是新的Linux
kernel，比如我们现在分析的Linux-2.6.24。使用的是bzImage，保护模式部分的内核代码被重定位到0x100000（即内存中的1M位置），并且内核中的实模式块（包括引导扇区boot
sector，设置部分setup，内存堆栈stack/heap）可以被重定位到0x10000（即4K）到低内存0xa0000（即640K）之间的任意位置。不幸的是，在协议protocols
2.00 和2.01中，0x90000之后的内存区间仍然被内核使用来放置实模式代码，但是2.02
protocol解决了这一个问题，不再像老内核zImage/Image使用0x90000之后的内存区间。
由于一些新的BIOS要在内存区域的0xA0000（即640K位置）的下面分配内存给扩展的BIOS区域使用。使用，这样留给EBDA
（Extended BIOS Data Area)的内存就多了。
&~&&&&&&&&&&&&&&&&&&&&&&&
&|& Protected-mode kernel |
从1M内存开始的是保护模式的代码
100000& +------------------------+
&|& I/O memory
hole&&&&&&
| 从640K到1M留给BIOS例程，并且映射ISA图形卡的内部内存
0A0000&+------------------------+
&|& Reserved for
|&这一部分的内存区要尽可能的多，扩展的BIO要用到这部分内存
&~&&&&&&&&&&&&&&&&&&&&&&&
&|& Command
line&&&&&&&&&
|&(Can also be below the X+10000 mark)
X+10000&+------------------------+
Stack/heap&&&&&&&&&&
&|&内核实模式代码（real-mode
code）使用的堆栈
X+08000&+------------------------+&
&|& Kernel
setup&&&&&&&&
&|&内核实模式代码(real-mode
code)代码的setup模块
&|& Kernel boot
&|&内核原来的引导模块（boot sector）
+------------------------+
loader&&&&&&&&&
&|&&- Boot
sector&（引导扇区boot
load的入口地址）0x赋值给CS：EIP
001000&+------------------------+
&|& Reserved for MBR/BIOS |
000800&+------------------------+
&|& Typically used by MBR |
000600&+------------------------+
&|& BIOS use
000000&+------------------------+
备注：此处的X是boot
load第一部分代码的结束位置一般是4K+512B的位置，它后面接着kernel实模式的代码。
第三部分 内核实模式代码头的数据结构分析
内核实模式代码头的左右是告诉boot load引导内核需要的具体设置，其基本结构如下：
位置在linux-2.6.24/include/asm-x86/bootparam.h
struct setup_header {
&__u8&setup_//引导扇区大小，此处值为4，代码四个扇区
&__u16&root_//Kernel中标识为READ_ONLY
&__u32&&&&//Protocol
2.06这个字段为4个字节,值为0x7F00，单位为16Byte
&__u16&ram_&
#define RAMDISK_IMAGE_START_MASK&0x07FF
RAMDISK_PROMPT_FLAG&&0x8000
RAMDISK_LOAD_FLAG&&0x4000
&__u16&vid_
&__u16&root_&&//根文件系统所在设备号，Linux-2.6.24内核中已经弃用，已经用命令行“root=...”代替
&__u16&boot_
//值为0xAA55，第一个扇区的结束标识
&__u16&&&&&&&//跳转指令
&__u32&&&&
//Magic signature "HdrS"
//Boot protocol version supported
&__u32&realmode_//Boot
loader hook
&__u16&start_&&&&
//The load-low segment (0x1000) (obsolete)
&__u16&kernel_//Pointer
to kernel version string
&__u8&type_of_ //Boot
loader identifier
&__u8&&&&&&
//&Boot protocol option flags
LOADED_HIGH&(1&&0)&
KEEP_SEGMENTS&(1&&6)
CAN_USE_HEAP&(1&&7)
&__u16&setup_move_//Move to
high memory size (used with hooks)
&__u32&code32_&&
//执行指向linux-2.6.24/arch/x86/boot/compressed/head_32.S中的startup_32函
&__u32&ramdisk_&
//initrd load address (set by boot loader)
&__u32&ramdisk_&&&//initrd
size (set by boot loader)
&__u32&bootsect_//DO NOT
USE - for bootsect.S use only
&__u16&heap_end_&&
//Free memory after setup end
&__u16&_pad1;&&&&&&&&&
&__u32&cmd_line_&&
//32-bit pointer to the kernel command line
&__u32&initrd_addr_//Highest
legal initrd address
&__u32&kernel_//Physical
addr alignment required for kernel
&__u8&relocatable_//Whether
kernel is relocatable or not
&__u8&_pad2[3];&&&&&&&&&
&__u32&cmdline_&&&&
//Maximum size of the kernel command line
&__u32&hardware_&//Hardware
subarchitecture
&__u64&hardware_subarch_
//Subarchitecture-specific data
一。这个数据结构由linux-2.6.24/arch/x86/boot/head.S中的汇编代码片段来填充，我们会在接下来的解析中详细分析。
二.为了向前兼容，setup_sects值为0时，真实值为4；boot protocol
2.04版本之前，syssize的前两个字节是不能使用的。这意味着bzImage的大小不能由它决定。
如果"Hdrs"(0x,这是小端存储，即H对应48，d对应64,...)在偏移0x202不能被发现，这说明boot
protocol的版本太老了，它加载的是一个旧内核，因此下面的参数将会被假设（参考Linux-0.11内核）：
&Image type = zImage
&initrd not supported
&Real-mode kernel must be located at 0x90000.
如果发现"Hdrs",那么"version"域存放的就是protocol版本号。当我们在填写这个代码头数据结构时，我们必须确保我们填写的各个域值是当前的这个protocol版本所支持的。
第四部分 实模式和保护模式引导概述
为了便于说明,我们以磁盘为例，第0扇区存放的是MBR，紧接着的setup_sects个扇区是kernel实模式的代码，其余的为Kernel保护模式代码。
在内核文件中，32位的保护模式的Kernel代码在偏移地址为(setup_sects+1)*512处启动，（注意：如果setup_sects==0,实际的值为4），如果是Image/zImage
kernels，它会被加载到0x10000（64K）内存地址处，如果是bzImage
kernels，它会被加载到内存0xM）处。
如果满足protocol&=2.00,同时0x01位（LOAD_HIGH）被置位，那么kernel是bzImage
kernel。代码如下：
&is_bzImage = (protocol
&= 0x0200) &&
(loadflags & 0x01);
&load_address = is_bzImage ? 0x100000 :
备注：Image/zImage
kernels至多有512K，它使用内存0x100的内存区间，这就意味着这些老内核的实模式部分的代码必须加载到0x90000处（参考：过程 ）而bzImage
kernel具有更大的灵活性，我们分析的linux-2.6.24就是bzImage kernel。
参考资料：
1.linux-2.6.24/Documentation/i386/boot.txt
2.Professional_Linux_Kernel_Architecture.Appendix D: System
3.Understanding the Linux Kernel 3rd Edition.Chapter 2. Memory
Addressing
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。Linux2.6内核和Linux2.4内核有什么不同？
Linux2.6内核和Linux2.4内核有什么不同？
| 时间： 20:16:01 | 阅读数：
模块子系统（Module Subsystem）、统一设备模型（Unified Device Model）和 PnP 支持模块子系统发生了重大变化。 2
稳定性有所提高 为了彻底避免内核加载或者导出正在被使用的内核模块，或者至少为
1. 模块子系统（Module Subsystem）、统一设备模型（Unified Device Model）和 PnP 支持模块子系统发生了重大变化。 2. 稳定性有所提高 为了彻底避免内核加载或者导出正在被使用的内核模块，或者至少为了减少加载或者卸载模块的同时使用该模块的可能性（这有时会导致系统崩溃），内核加载和导出内核模块的过程都得到了改进。 一定注意，升级前备份系统，防止升级出错造成重大损失，也要防止硬件不兼容、应用系统不兼容问题，最好先测试一下，再上线运行！ 3.统一设备模型 统一设备模型的创建是 2.6 内核最重要的变化之一。它促进了模块接口的标准化，其目的是更好地控制和管理设备，例如：更准确地确定系统设备。 电源管理和设备电源状态。 改进的系统总线结构管理。 4.即插即用（PnP）支持 运行 2.6 内核的 Linux 成为一个真正即插即用的 OS。例如，对 ISA PnP 扩展、遗留 MCA 和 EISA 总线以及热插拔设备的 PnP 支持。 5.内核基础设施的变化 为了区别以 .o 为扩展名的常规对象文件，内核模块现在使用的扩展名是 .ko。 创建了新的 sysfs 文件系统，当内核发现设备树时就会描述它。 内存支持，NUMA 支持 ,支持更大数量的 RAM。2.6 内核支持更大数量的 RAM，在分页模式下最高可达 64GB。 6.NUMA 对非一致内核访问（Non-Uniform Memory Access - NUMA）系统的支持是 2.6 内核中新出现的。 7.线程模型，NPTL 相对于 v2.4 的 LinuxThreads，在版本 2.6 中新出现的是 NPTL（Native POSIX Threading Library）。 NPTL 为 Linux 带来了企业级线程支持，提供的性能远远超过了 LinuxThreads。它所基于的用户与内核线程的比率是 1:1。 在 2003 年 10 月，GNU C 程序库 glibc 中融入了 NPTL 支持，Red Hat 率先在 Red Hat Linux 9 和 Red Hat Enterprise Linux 中使用定制的 v2.4 内核实现了 NPTL。 8.性能改进 新的调度器算法 ，2.6 Linux 内核引入了新的 O(1) 算法。在高负载情况下它运行得特别好。新的调度器基于每个 CPU 来分布时间片， 这样就消除了全局同步和重新分配循环，从而提高了性能。 内核抢占（Kernel Preemption） ，新的 2.6 内核是抢占式的。这将显著地提高交互式和多媒体应用程序的性能。 I/O 性能改进，Linux 的 I/O 子系统也发生了重大的变化，通过修改 I/O 调度器来确保不会有进程驻留在队列中过长时间等待进行输入/输出操作， 这样就使得 I/O 操作的响应更为迅速。 快速用户空间互斥（Fast User-Space Mutexes） ，“futexes”（快速用户空间互斥）可以使线程串行化以避免竞态条件，引入它也提高了响应速度。 通过在内核空间中部分实现“futexes”以允许基于竞争设置等待任务的优先级而实现改进。 9.扩展性改进 处理器数目更多，Linux 内核 2.6 最多可以支持 64 个 CPU。支持更大的内存，归功于 PAE（物理地址扩展，Physical Address Extensions），在 32-位系统上分页模式下所支持的内存增加到了 64GB。 用户和组，惟一用户和组的数量从 65，000 增至 40 多亿，也就是从 16-位增加到了 32-位。 PID 的数量，PID 的最大数量从 32，000 增至 10 亿。 打开文件描述符的数量，打开文件描述符的数量没有增加，但是不再需要事先设置该参数，它将自行调节。 10.支持更多的设备 在 Linux 内核 2.6 之前，内核中有可以约束大型系统的限制，比如每条链 256 个设备。v2.6 内核彻底地打破了这些限制， 不但可以支持更多类型的设备，而且支持更多同类型的设备。在 Linux 2.6 系统中，可以支持 4095 种主要的设备类型， 每一个单独的类型可以有超过一百万个子设备。 文件系统大小， Linux 内核 2.6 所允许的可寻址文件系统大小最大为 16 TB。 11.文件系统 ext2、ext3 和 ReiserFS 等传统 Linux 文件系统得到了显著的改进。最值得注意的改进是扩展属性（或文件元数据）的引入。 最重要的是 POSIX ACL 的实现，这是对普通 UNIX 权限的扩展，可以支持更细化的用户访问控制。 12.除了对传统 Linux 文件系统的改进支持以外，新的内核完全支持在 Linux 中相对较新的 XFS 文件系统。 Linux 2.6 内核现在还引入了对 NTFS 文件系统的改进的支持，现在允许以读/写模式安装 NTFS 文件系统。 【相关文章】
手机扫描下方二维码，关注php100官方微信。
同步官网每日更新，为您带来随时随地的资讯与技术信息。更有不定期的互动抽奖活动，赢取实用贴心的小礼物。
除非特别声明，PHP100新闻均为原创或投稿报道，转载请注明作者及原文链接原文地址：
友情链接与合作伙伴
粤ICP备号-3