linux内核视频教程（哪家的S5PV210开发板有视频教程呢主要是Linux和Android部分）

本文目录

• 哪家的S5PV210开发板有视频教程呢主要是Linux和Android部分
• 内存为程序分配空间的四种分配方式
• 内存映射：小块内存申请brk和申请大块内存的Mmap分析
• 哪里有linux命令行和内核的视频教程多谢！
• 一文读懂Linux任务间调度原理和整个执行过程

哪家的S5PV210开发板有视频教程呢主要是Linux和Android部分

目前210开发板视频很少，基本没有专门为某个开发板录的，基本都是第三方的。相比而言，飞凌的OK210视频还多一点儿，给你个目录参考一下吧。Android视频1、飞凌S5PV210开发板Android编译环境搭建视频教程2、飞凌S5PV210开发板Android源码编译视频教程3、飞凌S5PV210开发板将Android烧写到开发板视频教程4、飞凌S5PV210开发板将Android开发环境搭建视频教程5、飞凌S5PV210开发板将Android应用开发实例视频教程WINCE视频1、飞凌S5PV210开发板wince环境搭建与编译视频教程2、飞凌S5PV210开发板初识bsp视频教程3、飞凌S5PV210开发板bootloader的启动流程视频教程4、飞凌S5PV210开发板LED驱动与应用程序开发视频教程5、飞凌S5PV210开发板串口驱动与应用程序开发视频教程6、飞凌S5PV210开发板摄像头驱动与应用程序开发视频教程Linux视频1、飞凌S5PV210开发板Windows7安装Ubuntu12.04(32位)虚拟机视频教程2、飞凌S5PV210开发板配置虚拟机环境视频教程3、飞凌S5PV210开发板Linux内核代码的下载视频教程4、飞凌S5PV210开发板移植新的Linux内核代码到开发板视频教程5、飞凌S5PV210开发板在新的Linux内核代码中增加网络驱动视频教程6、飞凌S5PV210开发板在新的Linux内核代码中增加LED驱动视频教程7、飞凌S5PV210开发板在新的Linux内核代码中增加串口驱动视频教程8、飞凌S5PV210开发板在新的Linux内核代码中增加LCD显示功能视频教程9、飞凌S5PV210开发板在新的Linux内核代码中增加电阻触摸功能视频教程10、飞凌S5PV210开发板编写Led应用程序视频教程11、飞凌S5PV210开发板编写串口测试应用程序视频教程QT视频1、飞凌S5PV210开发板QTcreator集成开发环境介绍视频教程2、飞凌S5PV210开发板helloworld视频教程3、飞凌S5PV210开发板ubuntu环境搭建视频教程4、飞凌S5PV210开发板如何在开发板上运行qt4.7程序视频教程5、飞凌S5PV210开发板应用开发实例视频教程裸机视频1、飞凌S5PV210开发板下载bin文件到开发板视频教程2、飞凌S5PV210开发板裸机开发环境搭建视频教程3、飞凌S5PV210开发板实例1：蜂鸣器实验视频教程4、飞凌S5PV210开发板实例2：LED流水灯实验视频教程5、飞凌S5PV210开发板实例3：按键实验视频教程6、飞凌S5PV210开发板实例4：串口操实验视频教程7、飞凌S5PV210开发板实例5：IIC实验视频教程8、飞凌S5PV210开发板实例6：PWM实验视频教程硬件设计视频1、飞凌S5PV210开发板AD10的安装视频教程2、飞凌S5PV210开发板AD10的介绍视频教程3、飞凌S5PV210开发板AD10元件库的制作方法视频教程4、飞凌S5PV210开发板AD10封装库的制作方法视频教程5、飞凌S5PV210开发板OK210最小系统可行性分析视频教程6、飞凌S5PV210开发板设计原理图视频教程7、飞凌S5PV210开发板生成PCB视频教程8、飞凌S5PV210开发板制板流程讲解视频教程

内存为程序分配空间的四种分配方式

存储器是个宝贵但却有限的资源。一流的操作系统，需要能够有效地管理及利用存储器。

内存为程序分配空间有四种分配方式：

1、连续分配方式

2、基本分页存储管理方式

3、基本分段存储管理方式

4、段页式存储管理方式

首先讲连续分配方式。 连续分配方式 出现的时间比较早，曾广泛应用于20世纪60~70年代的OS中，但是它至今仍然在内存管理方式中占有一席之地，原因在于它 实现起来比较方便，所需的硬件支持最少 。连续分配方式又可细分为四种： 单一连续分配、固定分区分配、动态分区分配和动态重定位分区分配 。

其中固定分区的分配方式，因为分区固定，所以缺乏灵活性，即 当程序太小时，会造成内存空间的浪费（ 内部碎片 ） ； 程序太大时，一个分区又不足以容纳，致使程序无法运行（ 外部碎片 ） 。但尽管如此，当一台计算机去控制多个相同对象的时候，由于这些对象内存大小相同，所以完全可以采用这种内存管理方式，而且是最高效的。这里我们可以看出存储器管理机制的多面性：没有那种存储器管理机制是完全没有用的，在适合的场合下，一种被认为最不合理的分配方案却可能称为最高效的分配方案。 一切都要从实际问题出发，进行设计。

为了解决固定分区分配方式的缺乏灵活性，出现了 动态分配方式 。动态分配方式采用一些 寻表（Eg： 空闲链表 ） 的方式，查找能符合程序需要的空闲内存分区。但代价是增加了系统运行的开销，而且内存空闲表本身是一个文件，必然会占用一部分宝贵的内存资源，而且有些算法还会增加内存碎片。

可重定位分区分配通过对程序实现成定位，从而可以将内存块进行搬移，将小块拼成大块，将小空闲“紧凑”成大空闲，腾出较大的内存以容纳新的程序进程。

连续分配方式 会形成许多“碎片”，虽然可以通过“紧凑”方式将许多碎片拼接成可用的大块空间，但须为之付出很大开销。所以提出了“ 离散分配方式 ”的想法。如果 离散分配的基本单位是页 ，则称为 分页管理方式 ；如果离散分配的基本单位是段，则称为 分段管理方式 。

分页存储管理是将一个进程的逻辑地址空间分成若干个大小相等的片，称为页面或页，并为各页加以编号，从0开始，如第0页、第1页等。相应地，也把内存空间分成与页面相同大小的若干个存储块，称为(物理)块或页框(frame)，也同样为它们加以编号，如0#块、1#块等等。在为进程分配内存时，以块为单位将进程中的若干个页分别装入到多个可以不相邻接的物理块中。由于进程的最后一页经常装不满一块而形成了不可利用的碎片，称之为“ 页内碎片 ”。

在分页系统中，允许将进程的各个页离散地存储在内存不同的物理块中（所以能实现离散分配方式） ，但系统应能保证进程的正确运行，即能在内存中找到每个页面所对应的物理块。为此，系统又为每个进程建立了一张页面映像表，简称 页表 。在进程地址空间内的所有页，依次在页表中有一页表项，其中记录了相应页在内存中对应的物理块号。在配置了页表后，进程执行时，通过查找该表，即可找到每页在内存中的物理块号。可见， 页表的作用是实现从页号到物理块号的地址映射 。

为了能够将用户地址空间中的 逻辑地址，变换为内存空间中的物理地址 ，在系统中必须设置 地址变换机构 。地址变换任务是借助于页表来完成的。

页表 的功能可由一组专门的寄存器来实现。由于寄存器成本较高，且大多数现代计算机的页表又很大，使页表项总数可达几千甚至几十万个，显然这些页表项不可能都用寄存器来实现，因此，页表大多驻留在内存中。因为一个进程可以通过它的PCB来时时保存自己的状态，等到CPU要处理它的时候才将PCB交给寄存器，所以，系统中虽然可以运行多个进程，但也只需要一个页表寄存器就可以了。

由于 页表是存放在内存中 的，这使得 CPU在每存取一个数据时，都要两次访问内存 。为了提高地址变换速度，在地址变化机构中增设了一个 具有并行查询能力的高速缓冲寄存器 ，又称为“联想寄存器”（Associative Lookaside Buffer）。

在单级页表的基础上，为了适应非常大的逻辑空间，出现了两级和多级页表，但是，他们的原理和单级页表是一样的，只不过为了适应地址变换层次的增加，需要在地址变换机构中增设外层的页表寄存器。

分段存储管理方式 的目的，主要是为了满足用户（程序员）在编程和使用上多方面的要求，其中有些要求是其他几种存储管理方式所难以满足的。因此，这种存储管理方式已成为当今所有存储管理方式的基础。

分段管理方式和分页管理方式在实现思路上是很相似的，只不过他们的基本单位不同。分段有 段表 ，也有 地址变换机构 ，为了提高检索速度，同样增设 联想寄存器（具有并行查询能力的高速缓冲寄存器） 。所以有些具体细节在这个不再赘述。

分页和分段的主要区别：

1、两者相似之处：两者 都采用离散分配方式，且都要通过地址映射机构来实现地址变换 。

2、两者的不同之处：

（1）页是信息的 物理单位 ，分页是为实现离散分配方式，以消减内存的外零头，提高内存的利用率。或者说，分页仅仅是由于 系统管理的需要 而不是用户的需要。段则是信息的 逻辑单位 ，它含有一组其意义相对完整的信息。 分段的目的是为了能更好地满足用户的需要 。

（2） 页的大小固定 且由系统决定，而 段的长度却不固定 。

（3）分页的作业地址空间是 一维 的，即单一的线性地址空间；而分段的作业地址空间则是 二维 的。

前面所介绍的分页和分段存储管理方式都各有优缺点。 分页系统能有效地 提高内存利用率 ，而分段系统则能很好地 满足用户需求 。 我们希望能够把两者的优点结合，于是出现了段页式存储管理方式。

段页式系统的基本原理，是分段和分页原理的结合，即 先将用户程序分成若干个段，再把每个段分成若干个页 ，并为每一个段赋予一个段名。在段页式系统中，地址结构由段号、段内页号和页内地址三部分组成。

和前两种存储管理方式相同，段页式存储管理方式同样需要增设联想寄存器。

离散分配方式 基于将一个进程直接分散地分配到许多不相邻的分区中的思想，分为分页式存储管理，分段式存储管理和段页式存储管理. 分页式存储管理旨在提高内存利用率，满足系统管理的需要，分段式存储管理则旨在满足用户(程序员)的需要，在实现共享和保护方面优于分页式存储管理，而段页式存储管理则是将两者结合起来，取长补短，即具有分段系统便于实现，可共享，易于保护，可动态链接等优点，又能像分页系统那样很好的解决外部碎片的问题，以及为各个分段可离散分配内存等问题，显然是一种比较有效的存储管理方式。

更多Linux内核视频教程文档资料免费领取【 内核 】自行获取。

内核学习网站：

Linux内核源码/内存调优/文件系统/进程管理/设备驱动/网络协议栈-学习视频教程-腾讯课堂

内存映射：小块内存申请brk和申请大块内存的Mmap分析

本文为内存部分最后一篇，介绍内存映射。内存映射不仅是物理内存和虚拟内存间的映射，也包括将文件中的内容映射到虚拟内存空间。这个时候，访问内存空间就能够访问到文件里面的数据。而仅有物理内存和虚拟内存的映射，是一种特殊情况。本文首先分析用户态在堆中申请小块内存的brk和申请大块内存的mmap，之后会分析内核态的内存映射机制vmalloc，kmap_atomic，swapper_pg_dir以及内核态缺页异常。

用户态调用malloc()会分配堆内存空间，而实际上则是完成了一次用户态的内存映射，根据分配空间的大小，内存映射对应的系统调用主要有brk()和mmap()(当然我们也可以直接调用mmap()来映射文件)。对小块内存（小于 128K），C 标准库使用 brk() 来分配，也就是通过移动堆顶的位置来分配内存。这些内存释放后并不会立刻归还系统，而是被缓存起来，这样就可以重复使用。而大块内存（大于 128K），则直接使用内存映射 mmap() 来分配，也就是在文件映射段找一块空闲内存分配出去。这两种方式，自然各有优缺点。

brk()方式的缓存，可以减少缺页异常的发生，提高内存访问效率。不过，由于这些内存没有归还系统，在内存工作繁忙时，频繁的内存分配和释放会造成内存碎片。

mmap() 方式分配的内存，会在释放时直接归还系统，所以每次 mmap() 都会发生缺页异常。在内存工作繁忙时，频繁的内存分配会导致大量的缺页异常，使内核的管理负担增大。这也是 malloc() 只对大块内存使用 mmap() 的原因。

brk()系统调用为sys_brk()函数，其参数brk是新的堆顶位置，而mm-》brk是原堆顶位置。该函数主要逻辑如下

在 do_brk_flags() 中，调用 find_vma_links() 找到将来的 vm_area_struct 节点在红黑树的位置，找到它的父节点、前序节点。接下来调用 vma_merge()，看这个新节点是否能够和现有树中的节点合并。如果地址是连着的，能够合并，则不用创建新的 vm_area_struct 了，直接跳到 out，更新统计值即可；如果不能合并，则创建新的 vm_area_struct，添加到anon_vma_chain 链表中，也加到红黑树中。

大块内存的申请通过mmap系统调用实现，mmap既可以实现虚拟内存向物理内存的映射，也可以映射文件到自己的虚拟内存空间。映射文件时，实际是映射虚拟内存到物理内存再到文件。

这里主要调用ksys_mmap_pgoff()函数，这里逻辑如下:

vm_mmap_pgoff()函数调用do_mmap_pgoff()，实际调用do_mmap()函数。这里get_unmapped_area()函数负责寻找可映射的区域，mmap_region()负责映射该区域。

更多Linux内核视频教程文本资料免费领取后台私信【 内核大礼包 】自行获取。

首先来看看寻找映射区的函数get_unmapped_area()。

mmap_region()首先会再次检测地址空间是否满足要求，然后清除旧的映射，校验内存的可用性，在一切均满足的情况下调用vma_link()将新创建的vm_area_struct结构挂在mm_struct内的红黑树上。

vma_link()本身是__vma_link()和__vma_link_file()的包裹函数

其中__vma_link()主要是链表和红黑表的插入，这属于基本数据结构操作，不展开讲解。

而__vma_link_file()会对文件映射进行处理，在file结构体中成员f_mapping指向address_space结构体，该结构体中存储红黑树i_mmap挂载vm_area_struct。

至此，我们完成了用户态内存的映射，但是此处仅在虚拟内存中建立了新的区域，尚未真正访问物理内存。物理内存的访问只有在调度到该进程时才会真正分配，即发生缺页异常时分配。

三. 用户态缺页异常   一旦开始访问虚拟内存的某个地址，如果我们发现，并没有对应的物理页，那就触发缺页中断，调用 do_page_fault()。这里的逻辑如下

find_vma()为红黑树查找操作，在此不做展开描述，下面重点看看handle_mm_fault()。这里经过一系列校验之后会根据是否是大页而选择调用hugetlb_fault()或者__handle_mm_fault()

__handle_mm_fault()完成实际上的映射操作。这里涉及到了由pgd, p4g, pud, pmd, pte组成的五级页表，页表索引填充完后调用handle_pte_fault()创建页表项。

handle_pte_fault()处理以下三种情况:

对于匿名页映射，流程如下:

映射文件do_fault()函数调用了fault函数，该函数实际会根据不同的文件系统调用不同的函数，如ext4文件系统中vm_ops指向ext4_file_vm_ops，实际调用ext4_filemap_fault()函数，该函数会调用filemap_fault()完成实际的文件映射操作。

file_map_fault()主要逻辑为:

前文提到了我们会通过主动回收或者被动回收的方式将物理内存已映射的页面回收至硬盘中，当数据再次访问时，我们又需要通过do_swap_page()将其从硬盘中读回来。do_swap_page() 函数逻辑流程如下：查找 swap 文件有没有缓存页。如果没有，就调用 swapin_readahead()将 swap 文件读到内存中来形成内存页，并通过 mk_pte() 生成页表项。set_pte_at 将页表项插入页表，swap_free 将 swap 文件清理。因为重新加载回内存了，不再需要 swap 文件了。

通过以上步骤，用户态的缺页异常就处理完毕了。物理内存中有了页面，页表也建立好了映射。接下来，用户程序在虚拟内存空间里面可以通过虚拟地址顺利经过页表映射的访问物理页面上的数据了。页表一般都很大，只能存放在内存中。操作系统每次访问内存都要折腾两步，先通过查询页表得到物理地址，然后访问该物理地址读取指令、数据。为了加快映射速度，我们引入了 TLB（Translation Lookaside Buffer），我们经常称为快表，专门用来做地址映射的硬件设备。它不在内存中，可存储的数据比较少，但是比内存要快。所以我们可以想象，TLB 就是页表的 Cache，其中存储了当前最可能被访问到的页表项，其内容是部分页表项的一个副本。有了 TLB 之后，我们先查块表，块表中有映射关系，然后直接转换为物理地址。如果在 TLB 查不到映射关系时，才会到内存中查询页表。

和用户态使用malloc()类似，内核态也有相应的内存映射函数：vmalloc()可用于分配不连续物理页（使用伙伴系统），kmem_cache_alloc()和kmem_cache_create()使用slub分配器分配小块内存，而kmalloc()类似于malloc()，在分配大内存的时候会使用伙伴系统，分配小内存则使用slub分配器。分配内存后会转换为虚拟地址，保存在内核页表中进行映射，有需要时直接访问。由于vmalloc()会带来虚拟连续页和物理不连续页的映射，因此一般速度较慢，使用较少，相比而言kmalloc()使用的更为频繁。而kmem_cache_alloc()和kmem_cache_create()会分配更为精准的小内存块用于特定任务，因此也比较常用。

相对于用户态，内核态还有一种特殊的映射：临时映射。内核态高端内存地区为了节省空间会选择临时映射，采用kmap_atomic()实现。如果是 32 位有高端地址的，就需要调用 set_pte 通过内核页表进行临时映射；如果是 64 位没有高端地址的，就调用 page_address，里面会调用 lowmem_page_address。其实低端内存的映射，会直接使用 __va 进行临时映射。

kmap_atomic ()发现没有页表的时候会直接创建页表进行映射。而 vmalloc ()只分配了内核的虚拟地址。所以访问它的时候，会产生缺页异常。内核态的缺页异常还是会调用 do_page_fault()，最终进入vmalloc_fault()。在这里会实现内核页表项的关联操作，从而完成分配，整体流程和用户态相似。

至此，我们分析了内存物理地址和虚拟地址的映射关系，结合前文页的分配和管理，内存部分的主要功能就算是大致分析清楚了，最后引用极客时间中的一幅图作为总结，算是全部知识点的汇总。

1、brk

2、mmap

3、page_fault

哪里有linux命令行和内核的视频教程多谢！

***隐藏网址***Linux版视频收集贴（Ubuntu全）不知道有没有你需要的

一文读懂Linux任务间调度原理和整个执行过程

在前文中，我们分析了内核中进程和线程的统一结构体task_struct，并分析进程、线程的创建和派生的过程。在本文中，我们会对任务间调度进行详细剖析，了解其原理和整个执行过程。由此，进程、线程部分的大体框架就算是介绍完了。本节主要分为三个部分：Linux内核中常见的调度策略，调度的基本结构体以及调度发生的整个流程。下面将详细展开说明。

Linux 作为一个多任务操作系统，将每个 CPU 的时间划分为很短的时间片，再通过调度器轮流分配给各个任务使用，因此造成多任务同时运行的错觉。为了维护 CPU 时间，Linux 通过事先定义的节拍率（内核中表示为 HZ），触发时间中断，并使用全局变量 Jiffies 记录了开机以来的节拍数。每发生一次时间中断，Jiffies 的值就加 1。节拍率 HZ 是内核的可配选项，可以设置为 100、250、1000 等。不同的系统可能设置不同的数值，可以通过查询 /boot/config 内核选项来查看它的配置值。

Linux的调度策略主要分为实时任务和普通任务。实时任务需求尽快返回结果，而普通任务则没有较高的要求。在前文中我们提到了task_struct中调度策略相应的变量为policy，调度优先级有prio, static_prio, normal_prio, rt_priority几个。优先级其实就是一个数值，对于实时进程来说，优先级的范围是 0 99；对于普通进程，优先级的范围是 100 139。数值越小，优先级越高。

实时调度策略主要包括以下几种

普通调度策略主要包括以下几种：

首先，我们需要一个结构体去执行调度策略，即sched_class。该类有几种实现方式

普通任务调度实体源码如下，这里面包含了 vruntime 和权重 load_weight，以及对于运行时间的统计。

在调度时，多个任务调度实体会首先区分是实时任务还是普通任务，然后通过以时间为顺序的红黑树结构组合起来，vruntime 最小的在树的左侧，vruntime最多的在树的右侧。以CFS策略为例，则会选择红黑树最左边的叶子节点作为下一个将获得 CPU 的任务。而这颗红黑树，我们称之为运行时队列（run queue），即struct rq。

其中包含结构体cfs_rq，其定义如下，主要是CFS调度相关的结构体，主要有权值相关变量、vruntime相关变量以及红黑树指针，其中结构体rb_root_cached即为红黑树的节点

对结构体dl_rq有类似的定义，运行队列由红黑树结构体构成，并按照deadline策略进行管理

对于实施队列相应的rt_rq则有所不同，并没有用红黑树实现。

下面再看看调度类sched_class，该类以函数指针的形式定义了诸多队列操作，如

调度类分为下面几种：

队列操作中函数指针指向不同策略队列的实际执行函数函数，在linux/kernel/sched/目录下，fair.c、idle.c、rt.c等文件对不同类型的策略实现了不同的函数，如fair.c中定义了

以选择下一个任务为例，CFS对应的是pick_next_task_fair，而rt_rq对应的则是pick_next_task_rt，等等。

由此，我们来总结一下：

有了上述的基本策略和基本调度结构体，我们可以形成大致的骨架，下面就是需要核心的调度流程将其拼凑成一个整体，实现调度系统。调度分为两种，主动调度和抢占式调度。

说到调用，逃不过核心函数schedule()。其中sched_submit_work()函数完成当前任务的收尾工作，以避免出现如死锁或者IO中断等情况。之后首先禁止抢占式调度的发生，然后调用__schedule()函数完成调度，之后重新打开抢占式调度，如果需要重新调度则会一直重复该过程，否则结束函数。

而__schedule()函数则是实际的核心调度函数，该函数主要操作包括选取下一进程和进行上下文切换，而上下文切换又包括用户态空间切换和内核态的切换。具体的解释可以参照英文源码注释以及中文对各个步骤的注释。

其中核心函数是获取下一个任务的pick_next_task()以及上下文切换的context_switch()，下面详细展开剖析。首先看看pick_next_task()，该函数会根据调度策略分类，调用该类对应的调度函数选择下一个任务实体。根据前文分析我们知道，最终是在不同的红黑树上选择最左节点作为下一个任务实体并返回。

下面来看看上下文切换。上下文切换主要干两件事情，一是切换任务空间，也即虚拟内存；二是切换寄存器和 CPU 上下文。关于任务空间的切换放在内存部分的文章中详细介绍，这里先按下不表，通过任务空间切换实际完成了用户态的上下文切换工作。下面我们重点看一下内核态切换，即寄存器和CPU上下文的切换。

switch_to()就是寄存器和栈的切换，它调用到了 __switch_to_asm。这是一段汇编代码，主要用于栈的切换， 其中32位使用esp作为栈顶指针，64位使用rsp，其他部分代码一致。通过该段汇编代码我们完成了栈顶指针的切换，并调用__switch_to完成最终TSS的切换。注意switch_to中其实是有三个变量，分别是prev, next, last，而实际在使用时，我们会对last也赋值为prev。这里的设计意图需要结合一个例子来说明。假设有ABC三个任务，从A调度到B，B到C，最后C回到A，我们假设仅保存prev和next，则流程如下

最终调用__switch_to()函数。该函数中涉及到一个结构体TSS(Task State Segment)，该结构体存放了所有的寄存器。另外还有一个特殊的寄存器TR（Task Register）会指向TSS，我们通过更改TR的值，会触发硬件保存CPU所有寄存器在当前TSS，并从新的TSS读取寄存器的值加载入CPU，从而完成一次硬中断带来的上下文切换工作。系统初始化的时候，会调用 cpu_init()给每一个 CPU 关联一个 TSS，然后将 TR 指向这个 TSS，然后在操作系统的运行过程中，TR 就不切换了，永远指向这个 TSS。当修改TR的值得时候，则为任务调度。

更多Linux内核视频教程文本资料免费领取后台私信【 内核大礼包 】自行获取。

在完成了switch_to()的内核态切换后，还有一个重要的函数finish_task_switch()负责善后清理工作。在前面介绍switch_to三个参数的时候我们已经说明了使用last的重要性。而这里为何让prev和last均赋值为prev，是因为prev在后面没有需要用到，所以节省了一个指针空间来存储last。

至此，我们完成了内核态的切换工作，也完成了整个主动调度的过程。

抢占式调度通常发生在两种情况下。一种是某任务执行时间过长，另一种是当某任务被唤醒的时候。首先看看任务执行时间过长的情况。

该情况需要衡量一个任务的执行时间长短，执行时间过长则发起抢占。在计算机里面有一个时钟，会过一段时间触发一次时钟中断，通知操作系统时间又过去一个时钟周期，通过这种方式可以查看是否是需要抢占的时间点。

时钟中断处理函数会调用scheduler_tick()。该函数首先取出当前CPU，并由此获取对应的运行队列rq和当前任务curr。接着调用该任务的调度类sched_class对应的task_tick()函数进行时间事件处理。

以普通任务队列为例，对应的调度类为fair_sched_class，对应的时钟处理函数为task_tick_fair()，该函数会获取当前的调度实体和运行队列，并调用entity_tick()函数更新时间。

在entity_tick()中，首先会调用update_curr()更新当前任务的vruntime，然后调用check_preempt_tick()检测现在是否可以发起抢占。

check_preempt_tick() 先是调用 sched_slice() 函数计算出一个调度周期中该任务运行的实际时间 ideal_runtime。sum_exec_runtime 指任务总共执行的实际时间，prev_sum_exec_runtime 指上次该进程被调度时已经占用的实际时间，所以 sum_exec_runtime - prev_sum_exec_runtime 就是这次调度占用实际时间。如果这个时间大于 ideal_runtime，则应该被抢占了。除了这个条件之外，还会通过 __pick_first_entity 取出红黑树中最小的进程。如果当前进程的 vruntime 大于红黑树中最小的进程的 vruntime，且差值大于 ideal_runtime，也应该被抢占了。

如果确认需要被抢占，则会调用resched_curr()函数，该函数会调用set_tsk_need_resched()标记该任务为_TIF_NEED_RESCHED，即该任务应该被抢占。

某些任务会因为中断而唤醒，如当 I/O 到来的时候，I/O进程往往会被唤醒。在这种时候，如果被唤醒的任务优先级高于 CPU 上的当前任务，就会触发抢占。try_to_wake_up() 调用 ttwu_queue() 将这个唤醒的任务添加到队列当中。ttwu_queue() 再调用 ttwu_do_activate() 激活这个任务。ttwu_do_activate() 调用 ttwu_do_wakeup()。这里面调用了 check_preempt_curr() 检查是否应该发生抢占。如果应该发生抢占，也不是直接踢走当前进程，而是将当前进程标记为应该被抢占。

由前面的分析，我们知道了不论是是当前任务执行时间过长还是新任务唤醒，我们均会对现在的任务标记位_TIF_NEED_RESCUED，下面分析实际抢占的发生。真正的抢占还需要一个特定的时机让正在运行中的进程有机会调用一下 __schedule()函数，发起真正的调度。

实际上会调用__schedule()函数共有以下几个时机

从系统调用返回用户态：以64位为例，系统调用的链路为do_syscall_64-》syscall_return_slowpath-》prepare_exit_to_usermode-》exit_to_usermode_loop。在exit_to_usermode_loop中，会检测是否为_TIF_NEED_RESCHED，如果是则调用__schedule()

内核态启动：内核态的执行中，被抢占的时机一般发生在 preempt_enable() 中。在内核态的执行中，有的操作是不能被中断的，所以在进行这些操作之前，总是先调用 preempt_disable() 关闭抢占，当再次打开的时候，就是一次内核态代码被抢占的机会。preempt_enable() 会调用 preempt_count_dec_and_test()，判断 preempt_count 和 TIF_NEED_RESCHED 是否可以被抢占。如果可以，就调用 preempt_schedule-》preempt_schedule_common-》__schedule 进行调度。

   本文分析了任务调度的策略、结构体以及整个调度流程，其中关于内存上下文切换的部分尚未详细叙述，留待内存部分展开剖析。

1、调度相关结构体及函数实现

2、schedule核心函数