基于i386体系结构的Linux实现特点剖析-内存与进程

内存管理
1、基本框架
　　Linux内核的设计要考虑到在各种不同的微处理器上的实现，还有考虑到在64位的微处理器(如Alpha)上的实现，所以不能仅仅针对i386结构 来设计它的映射机制，而要以只要假象的、虚拟的微处理器和MMU(内存管理单元)为基础，设计出一种通用的模式，再把它分别落实到具体的微处理器上。因 此，Linux内核的映射机制被设计成三层，在页面目录和页表之间增设了一层“中间目录”。在代码中，页面目录称为PGD,中间目录称为PMD，而页表称 为PT。PT的表项称为PTE。PGD，PMD，PT均为数组，相应的，在逻辑上也把线性地址从高到低分为4各位段，个占若干位，分别用作目录PGD的下 标、中间目录PMD的下标、页表中的下标和物理页面内的位移。
　　就i386微处理器来说，CPU实际上不是按三层而是按两层的模型来进行地址映射，这就需要将虚拟的三层映射落实到具体的两层的映射，跳过中间的PMD层次。
2、地址映射的全过程
　　i386微处理器一律对程序中的地址先进行段式映射，然后才能进行页式映射。而Linux所采用的方法实际上使段式映射的过程中不起什么作用。
　　下面通过一个简单的程序来看看Linux下的地址映射的全过程：


  #include
  greeting()
  {
      printf(“Hello world!
”);
  }
  main()
  {
      greeing();
  }

　　该程序在主函数中调用greeting 来显示“Hello world!”，经过编译和反汇编，我们得到了它的反汇编的结果。

08048568:
8048568: 55                push1 %ebp
8048856b:89 e5            mov1 %esp,%ebp
804856b: 68 04 94 04 08    push1 $0x8048404
8048570: e8 ff fe ff ff    call 8048474
8048575: 83 c4 04          add1 $0x4,%esp
8048578: c9                leave
8048579: c3                ret
804857a: 89 f6            mov1 %esi,%esi
0804857c :
804857c: 55                push1 %ebp
804857d: 89 e5            mov1 %esp,%ebp
804857f: e8 e4 ff ff ff    call 8048568
8048584: c9                leave
8048585: c3                ret
8048586: 90                nop
8048587: 90                nop

　　从上面可以看出，greeting()的地址为0x8048568。在elf格式的可执行代码中，总是在0x8000000开始安排程序的“代码段”，对每个程序都是这样。
　　当程序在main中执行到了“call 8048568”这条指令，要转移到虚拟地址8048568去。
　　首先是段式映射阶段。地址8048568是一个程序的入口，更重要的是在执行的过程中有CPU的EIP所指向的，所以在代码段中。I386cpu使用CS的当前值作为段式映射的选择子。
　　内核在建立一个进程时都要将其段寄存器设置好，把DS、ES、SS都设置成_USER_DS,而把CS设置成_USER_CS,这也就是说，在Linux内核中堆栈段和代码段是不分的。

                        Index          TI DPL
#define_KERNEL_CS 0x10  0000 0000 0001 0|0|00 
#define_KERNEL_DS 0x18  0000 0000 0001 1|0|00 
#define_USER_CS 0x23  0000 0000 0010 0|0|11
#define_USER_DS 0x2B  0000 0000 0010 1|0|11
_KERNEL_CS:        index=2,TI=0,DPL=0
_KERNEL_DS:        index=3,TI=0,DPL=0   
_USERL_CS:          index=4,TI=0,DPL=3
_USERL_DS:          index=5,TI=0,DPL=3

　　TI全都是0，都使用全局描述表。内核的DPL都为0，最高级别；用户的DPL都是3，最低级别。_USER_CS在GDT表中是第4项，初始化GDT内容的代码如下：

  ENTRY(gdt-table)
      .quad 0x0000000000000000  /* NULL descriptor */
      .quad 0x0000000000000000  /* not used */
      .quad 0x00cf9a00000ffff    /* 0x10 kernel 4GB code at 0x00000000 */
      .quad 0x00cf9200000ffff    /* 0x18 kernel 4GB data at 0x00000000 */
      .quad 0x00cffa00000ffff    /* 0x23 user 4GB code at 0x00000000 */
      .quad 0x00cff200000ffff    /* 0x2b user 4GB data at 0x00000000 */

  GDT 表中第一、二项不用，第三至第五项共四项对应于前面的四个段寄存器的数值。
将这四个段描述项的内容展开：

  K_CS:  0000 0000 1100 1111 1001 1010 0000 0000
        0000 0000 0000 0000 1111 1111 1111 1111
  K_DS:  0000 0000 1100 1111 1001 0010 0000 0000
        0000 0000 0000 0000 1111 1111 1111 1111
  U_CS:  0000 0000 1100 1111 11111 1010 0000 0000
        0000 0000 0000 0000 1111 1111 1111 1111
  U_DS:  0000 0000 1100 1111 1111 0010 0000 0000
        0000 0000 0000 0000 1111 1111 1111 1111

　　这四个段描述项的下列内容都是相同的。
     
    ·BO-B15/B16-B31 都是0    基地址全为0
    ·LO-L15、L16-L19都是1    段的界限全是0xfffff
    ·G位都是1                段长均为4KB
    ·D位都是1                32位指令
    ·P位都是1                四个段都在内存中
    不同之处在于权限级别不同，内核的为0级，用户的为3级。

　　由此可知，每个段都是从地址0开始的整个4GB地虚存空间，虚地址到线性地址的映射保持原值不变。
　　再回到greeting 的程序中来，通过段式映射把地址8048568映射到自身，得到了线性地址。
　　每个进程都有自身的页目录PGD，每当调度一个进程进入运行时，内核都要为即将运行的进程设置好控制寄存器CR3，而MMU硬件总是从CR3中取得当前进程的页目录指针。
　　当程序要转到地址0x8048568去的时候，进程正在运行中，CR3已经设置好了，指向本进程的页目录了。

    8048568： 0000 1000 0000 0100 1000 0101 0110 1000

　　按照线性地址的格式，最高10位 0000100000，十进制的32，就以下标32去页目录表中找其页目录项。这个页目录项的高20位后面添上12个0就得到该页面表的指针。找到页表 后，再看线性地址的中间10位001001000，十进制的72。就以72为下标在找到的页表中找到相应的表项。页面表项重的高20位后添上12个0就得 到了物理内存页面的基地址。线性地址的底12位和得到的物理页面的基地址相加就得到要访问的物理地址。
3 地址映射的效率分析
　　在页式映射的过程中，CPU要访问内存三次，第一次是页面目录，第二次是页面表，第三次才是真正要访问的目标。这样，把原来不用分页机制一次访问内存就能得到的目标，变为三次访问内存才能得到，明显执行分页机制在效率上的牺牲太大了。
　　为了减少这种开销，最近被执行过的地址转换结果会被保留在MMU的转换后备缓存（TLB）中。虽然在第一次用到具体的页面目录和页面表时要到内存中读取，但一旦装入了TLB中，就不需要再到内存中去读取了，而且这些都是由硬件完成的，因此速度很快。
　　TLB对应权限大于0级的程序来说是不可见的，只有处于系统0层的程序才能对其进行操作。
　　当CR3的内容变化时，TLB中的所有内容会被自动变为无效。Linux中的_flush_tlb宏就是利用这点工作的。_flush_tlb只是两 条汇编指令，把CR3的值保存在临时变量tmpreg里，然后立刻把tmpreg的值拷贝回CR3，这样就将TLB中的全部内容置为无效。除了无效所有的 TLB中的内容，还能有选择的无效TLB中某条记录，这就要用到INVLPG指令。

五、进程管理
1.I386硬件任务切换机制
　　Intel 在i386体系的设计中考虑到了进程的管理和调度，并从硬件上支持任务间的切换。为此目的，Intel在i386系统结构中增设了一种新的段“任务状态 段”TSS。一个TSS虽然说像代码段，数据段等一样，也是一个段，实际上却是一个104字节的数据结构，用以记录一个任务的关键性的状态信息。
　　像其他段一样，TSS也要在段描述表中有个表项。不过TSS只能在GDT中，而不能放在任何一个LDT中或IDT中。若通过一个段选择项访问一个TSS，而选择项中的TI位为1，就会产生一次GP异常。
　　另外，CPU中还增设一个任务寄存器TR,指向当前任务的TSS。相应地，还增加了一条指令LTR,对TR寄存器进行装入操作。像CS和DS一样， TR也有一个程序不可见部分，每当将一个段选择码装入到TR中时，CPU就会自动找到所选择的TSS描述项并将其装入到TR的程序不可见部分，以加速以后 对该TSS段的访问。
　　还有，在IDT表中，除了中断门、陷阱门和调用门以为，还定义了一种任务门。任务门中包含一个TSS段选择码。当CPU因中断而穿过一个任务门时，就 会将任务门中的选择码自动装入TR，使TR指向新的TSS，并完成任务的切换。CPU还可以通过JMP和CALL指令实现任务切换，当跳转或调用的目标段 实际上指向GDT表中的一个TSS描述项时，就会引起一次任务切换。
2. Linux的任务切换和现场保护
　　Intel 关于任务切换的设计十分的周到，而且提供了十分简洁的任务切换机制。但是，Linux并不采用i386硬件提供的任务切换机制。  Linux之所以这样做，很大程度是从效率的角度考虑。有CPU自动完成的这种任务切换并不是只相当于一条指令。实际上，i386中通过JMP指令或 CALL指令完成任务切换的过程是一个相当复杂的过程，其执行过程长达300多个CPU时钟周期。在执行过程，CPU实际上做了所有需要做的事，而其中有 的事在一定条件下可以简化的，有的事则可能在一定条件下应该按不同的方式组合。所以，i386CPU所提供的这种任务切换机制就好像是一种“高级语言”的 成分。但对应操作系统的设计和实现而言，往往会选择“汇编语言”来实现这个机制，以达到更高的效率和更大的灵活性。更重要的是，任务的切换往往不是孤立 的，常常跟其他操作联系紧密。
　　Linux内核为了满足i386CPU的要求，只是在初始化的时候设置TR，使之指向一个TSS，从此以后就不再修改TR的值。也就是说，每个CPU 在初始化以后就永远使用同一个TSS。同时，内核也不依靠TSS保存每个进程切换时的寄存器副本，而是将这些寄存器的副本保存在各自进程的系统空间堆栈 中。
六、结语
　　本文详细描述i386保护模式，详细分析Linux的中断管理、段页式管理以及任务切换等功能在i386体系结构上的实现机制。这些时一个操作系统中与硬件相关较多的部分，是操作系统较底层的部分。