Linux进程管理（一）进程数据结构

你的名字 2023-06-10 11:28 2阅读 0赞

**Linux进程管理**

[Linux进程管理（一）进程数据结构][Linux]

[Linux进程管理（二）进程调度][Linux 1]

[Linux进程管理（三）进程调度之主动调度][Linux 2]

[Linux进程管理（四）进程调度之抢占式调度][Linux 3]

# Linux进程管理（一）进程数据结构 #

### 文章目录 ###

*  Linux进程管理（一）进程数据结构
 *   *  双向链表
     *  任务ID
     *  信号处理
     *  进程状态
     *  进程调度
     *  运行统计信息
     *  进程亲缘关系
     *  内存管理
     *  文件与文件系统
     *  进程内核栈
     *   *  栈结构
         *  current宏

Linux内核中使用 `task_struct` 结构来表示一个进程，这个结构体保存了进程的所有信息，所以它非常庞大，在讲解Linux内核的进程管理，我们有必要先分析这个 `task_struct` 中的各项成员

## 双向链表 ##

struct list_head tasks;

Linux将所有的 task\_struct 串联成一个双向循环链表

## 任务ID ##

pid_t pid;
    pid_t tgid;
    
    struct task_struct *group_leader;

*  pid：每个进程都有自己的 `pid`，它在内核中是唯一的，在Linux中，我们可以使用 `ps -ef`查看所有的进程，其中 PID 就是进程号。pid可以给用户查看指定进程的信息，可以通过pid给指定的进程发送信号
 *  tgid：tigd 是 thread group ID，表示线程组id。thread group 是线程组的意思，所谓的线程组是什么意思呢？内核中不管是线程或者是进程都是使用 task\_struct 来表示，一个进程也可以称为主线程，由它创建多个线程，这些线程和进程的主线程就称为一个线程组。每个线程都有自己的pid，而 tgid 则等于进程的主线程的 pid，这样也就可以区分谁是主线程，谁是被主线程创建出来的
 *  group\_leader：指向线程组主线程的进程描述符

通过 getpid 返回的是 tgid，也就是说同一个线程组共享一个 pid

## 信号处理 ##

/* Signal handlers: */
    struct signal_struct    *signal;
    struct sighand_struct    *sighand;
    sigset_t      blocked;
    sigset_t      real_blocked;
    sigset_t      saved_sigmask;
    struct sigpending    pending;
    unsigned long      sas_ss_sp;
    size_t        sas_ss_size;
    unsigned int      sas_ss_flags;

*  blocked：sigset\_t 是一个位图，每个位都表示一个信号。blocked 表示的是该进程的哪些信号被阻塞暂不处理
 *  pending：表示进程接收到了哪些信号，需要被处理
 *  sighand：用户可以定义相应信号的处理方法，其信息保存在这里
 *  sas\_ss\_xxx：信号的处理默认使用的是进程用户空间的函数栈，也可以开辟新的栈专门用于信号处理，这三个变量就是用户维护这个栈信息  
    在 signal 中，定义了 struct sigpending shared\_pending，这个 shared\_pending 和 pending 的区别是，pending 表示该 task\_struct 收到的信号，而 shared\_pending 是整个线程组共享的。也就是说，对于 pending 中接收到的信号，只能由这个 task\_struct 来处理，而 shared\_pending 中收到的信号，可以由线程组中的任意一个线程处理

## 进程状态 ##

在 task\_struct 中，定义了这样几个变量，与进程的状态有关

volatile long state;    /* -1 unrunnable, 0 runnable, >0 stopped */
     int exit_state;
     unsigned int flags;

**state 和 exit\_state 的定义如下**

/* Used in tsk->state: */
    #define TASK_RUNNING                    0
    #define TASK_INTERRUPTIBLE              1
    #define TASK_UNINTERRUPTIBLE            2
    #define __TASK_STOPPED                  4
    #define __TASK_TRACED                   8
    /* Used in tsk->exit_state: */
    #define EXIT_DEAD                       16
    #define EXIT_ZOMBIE                     32
    #define EXIT_TRACE                      (EXIT_ZOMBIE | EXIT_DEAD)

**state相关**

*  TASK\_RUNNING：运行态或就绪态，表示进程正在运行，或者进程处于就绪态位于运行队列中
 *  TASK\_INTERRUPTIBLE：可中断的睡眠态，表示进程正在睡眠等待，睡眠过程中可以被信号唤醒
 *  TASK\_UNINTERRUPTIBLE：不可中断的睡眠态，表示进程正在睡眠等待，并且睡眠过程中不可被信号唤醒。这就意味着，如果有一个进程一直处于这种状态，我们无法使用信号将其杀死，唯一的办法就是重启，所以这个状态较少使用
 *  \_\_TASK\_STOPPED：在进程收到 SIGSTOP、SIGTTIN、SIGTSTP 或者 SIGTTO 等信号的时候，进入该状态
 *  \_\_TASK\_TRACED：进程被另一个进程跟踪的时候，进入此状态

**exit\_state相关**

*  EXIT\_ZOMBIE：僵尸态，如果一个进程已经死亡，但在内核中的 task\_struct 还未被父进程回收，那么进程就会变成僵尸进程
 *  EXIT\_DEAD：最终态，进程的资源被父进程回收后，会从 EXIT\_ZOMBIE 变成 EXIT\_DEAD

**进程的状态转换如下**

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQ2MjIwMg_size_16_color_FFFFFF_t_70]

**flags的某些定义如下**

#define PF_EXITING    0x00000004
    #define PF_VCPU      0x00000010
    #define PF_FORKNOEXEC    0x00000040

*  PF\_EXITING：表示正在退出
 *  PF\_VCPU：表示运行在虚拟CPU上
 *  PF\_FORKNOEXEC：表示 fork 完，还没有调用 exec

## 进程调度 ##

进程调度相关的变量如下

//是否在运行队列上
    int        on_rq;
    //优先级
    int        prio;
    int        static_prio;
    int        normal_prio;
    unsigned int      rt_priority;
    //调度器类
    const struct sched_class  *sched_class;
    //调度实体
    struct sched_entity    se;
    struct sched_rt_entity    rt;
    struct sched_dl_entity    dl;
    //调度策略
    unsigned int      policy;
    //可以使用哪些CPU
    int        nr_cpus_allowed;
    cpumask_t      cpus_allowed;
    struct sched_info    sched_info;

*  on\_rq：表明进程是否在运行队列上
 *  prio、static\_prio、normal\_prio、rt\_priority：优先级相关的变量
 *  sched\_class：调度类，也就是这个进程采用的调度策略
 *  se、rt、dl：调度实体，调度类操作的单位
 *  policy：调度策略，与 sched\_class 对应
 *  nr\_cpus\_allowed、cpus\_allowed：表明进程可以在哪些CPU上运行

## 运行统计信息 ##

u64        utime;//用户态消耗的CPU时间
    u64        stime;//内核态消耗的CPU时间
    unsigned long      nvcsw;//自愿(voluntary)上下文切换计数
    unsigned long      nivcsw;//非自愿(involuntary)上下文切换计数
    u64        start_time;//进程启动时间，不包含睡眠时间
    u64        real_start_time;//进程启动时间，包含睡眠时间

## 进程亲缘关系 ##

struct task_struct __rcu *real_parent; /* real parent process */
    struct task_struct __rcu *parent; /* recipient of SIGCHLD, wait4() reports */
    struct list_head children;      /* list of my children */
    struct list_head sibling;       /* linkage in my parent's children list */

进程之间有亲缘关系，所以所有的进程实际上是一棵树，上面说过，进程组成一个双向循环链表，这并不冲突，因为既是双向循环链表，又是一棵树

*  parent：指向父进程
 *  children：所有子进程的组成的链表的链表头
 *  sibling：兄弟链表，又相当于父进程的 children 链表中的一个节点

所有进程组成的关系如下

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQ2MjIwMg_size_16_color_FFFFFF_t_70 1]

real\_parent 和 parent 在大多数情况下是一样的，只有在某些特殊情况下才会不一样

## 内存管理 ##

struct mm_struct                *mm;
    struct mm_struct                *active_mm;

每个进程都有自己独立的地址空间，内核使用了 mm\_struct 结构体来管理进程的地址空间

## 文件与文件系统 ##

/* Filesystem information: */
    struct fs_struct                *fs;
    /* Open file information: */
    struct files_struct             *files;

每个进程都有一个文件系统的数据结构，就是 fs\_struct

每个进程还要维护它所打开的文件，这些信息在 files\_struct 中

## 进程内核栈 ##

### 栈结构 ###

上面讲解了 task\_struct 的大部分成员，下面来讲解进程的内核栈

程序的运行需要使用到栈，所以不管进程是在内核态运行还是在用户态运行都需要用到栈

Linux将进程地址空间分为内核空间和用户空间，它们之间是不能直接访问的，而一个进程某些时候可能在用户态运行，某些时候可能在内核态运行（发生系统调用时），所以一个进程既需要用户栈又需要内核栈

下面就来讲解内核给进程分配的栈结构

在 task\_struct 中，有一个变量指向该进程的内核栈，如下

struct task_struct {
        
        ...
        void *stack;
    	...	
    };

内核栈的大小在内核中的定义如下

#define THREAD_SIZE_ORDER  1
    #define THREAD_SIZE    (PAGE_SIZE << THREAD_SIZE_ORDER)

一个 PAGE\_SIZE 是4K，左移一位就是乘以2，所以 THREAD\_SIZE 就是8K，所以大体j结构如下

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQ2MjIwMg_size_16_color_FFFFFF_t_70 2]

接下来我们看这8K的空间的结构分布

在这段空间的最底部，存放着一个 struct thread\_info 结构体，何以证明呢？

在Linux中有一个 union thread\_union 共用体，其定义如下

union thread_union {
        
    #ifndef CONFIG_THREAD_INFO_IN_TASK
      struct thread_info thread_info;
    #endif
      unsigned long stack[THREAD_SIZE/sizeof(long)];
    };

其中的 stack 表示栈空间，大小为 THREAD\_SIZE 个字节

union 表示是一个共用体，可以看出，thread\_info 在位于这个栈的最底部，如下图所示

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQ2MjIwMg_size_16_color_FFFFFF_t_70 3]

Linux中发生系统调用时，会从用户态变成内核态，然后执行内核代码，当内核代码执行完之后，又会回到用户态执行用户代码

在进程从用户态变成内核态的时候，内核需要将用户态运行时寄存器的值保存下来，然后修改寄存器，当内核代码执行完之后，又将寄存器的值恢复，这些寄存器的值保存在哪里呢？

在内核栈的最高端，存放着一个 pt\_regs 结构，这个结构包含了相关寄存器的定义，用户态寄存器的值就保存在这里，对于X86 32 位其定义如下

struct pt_regs {
        
      unsigned long bx;
      unsigned long cx;
      unsigned long dx;
      unsigned long si;
      unsigned long di;
      unsigned long bp;
      unsigned long ax;
      unsigned long ds;
      unsigned long es;
      unsigned long fs;
      unsigned long gs;
      unsigned long orig_ax;
      unsigned long ip;
      unsigned long cs;
      unsigned long flags;
      unsigned long sp;
      unsigned long ss;
    };

此外剩余的空间才是用作函数栈，栈是向下生长的，所以进程的内核栈就变成下面这个样子

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQ2MjIwMg_size_16_color_FFFFFF_t_70 4]

接下来看 thread\_info 的定义，如下

struct thread_info {
        
      struct task_struct  *task;    /* main task structure */
      __u32      flags;    /* low level flags */
      __u32      status;    /* thread synchronous flags */
      __u32      cpu;    /* current CPU */
      mm_segment_t    addr_limit;
      unsigned int    sig_on_uaccess_error:1;
      unsigned int    uaccess_err:1;  /* uaccess failed */
    };

thread\_info 中有一个变量 task\_struct，指向拥有这个内核栈的进程，如下所示

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQ2MjIwMg_size_16_color_FFFFFF_t_70 5]

### current宏 ###

Linux内核中可以通过 current 宏来获取当前正在运行的进程，它的实现十分巧妙，下面我们一起来看一看

#define get_current() (current_thread_info()->task)
    #define current get_current()

current 通过 get\_current()，进而调用 current\_thread\_info()->task

我们看一看 current\_thread\_info 的定义

static inline struct thread_info *current_thread_info(void)
    {
        
    	return (struct thread_info *)
    		(current_stack_pointer & ~(THREAD_SIZE - 1));
    }

current\_stack\_pointer 表示当前栈顶寄存器的值，对于 X86 就是 esp，在内核态的时候，current\_stack\_pointer 表示内核栈中的某一个位置

THREAD\_SIZE 我们上面说过是8K，THREAD\_SIZE - 1 就是8K剩下的所有位，如下

![在这里插入图片描述][20191027164419656.png]

那么这个操作是什么意思呢？

(current_stack_pointer & ~(THREAD_SIZE - 1)

意思就是将 current\_stack\_pointer 的低12位清空

我们从这个 current\_thread\_info 函数可以看出，通过这个操作就可以获得 thread\_info 对象，这是为什么呢？

这是因为，内核栈在申请的时候，总是 8K 对齐的，也就是说地址的低12位肯定为0

当进程在内核态运行的时候，栈顶指针总是指向这块申请的内核栈中的某一个区域，内核栈的大小最大也就8K，所以将当前栈顶指针的低12位置零就可以得到内核栈的基址

而 thread\_info 存在于内核栈的栈底处，所以也就获取到了该进程对应的 thread\_info 结构

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQ2MjIwMg_size_16_color_FFFFFF_t_70 6]

thread\_info 结构中有一个 task\_struct\* 成员，指向该进程的 task\_struct，所以也就可以获得该进程的 task\_struct 结构

不禁感叹，Linux内核的实现真是巧妙啊

好了，关于Linux进程的数据结构就介绍到这里了，后面的文章将讲解Linux的进程调度

[Linux]: https://blog.csdn.net/weixin_42462202/article/details/102768721
[Linux 1]: https://blog.csdn.net/weixin_42462202/article/details/102887008
[Linux 2]: https://blog.csdn.net/weixin_42462202/article/details/102933986
[Linux 3]: https://blog.csdn.net/weixin_42462202/article/details/102954818
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQ2MjIwMg_size_16_color_FFFFFF_t_70]: /images/20230531/8984b029b0844df5b3b552c124c52877.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQ2MjIwMg_size_16_color_FFFFFF_t_70 1]: /images/20230531/d2e23cfa632d4406b961690b385c0585.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQ2MjIwMg_size_16_color_FFFFFF_t_70 2]: /images/20230531/0defd741d9ac479c99a7eda6489f2d76.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQ2MjIwMg_size_16_color_FFFFFF_t_70 3]: /images/20230531/e6f55e0b49974f2ab2cf9779c909ea1f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQ2MjIwMg_size_16_color_FFFFFF_t_70 4]: /images/20230531/ca47d856e0934cec9a0044bc9d98ea45.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQ2MjIwMg_size_16_color_FFFFFF_t_70 5]: /images/20230531/03e10b5d29714e728163fab8c31dbd4e.png
[20191027164419656.png]: /images/20230531/ca0e83ecff954115b53d3eacd70628da.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQ2MjIwMg_size_16_color_FFFFFF_t_70 6]: /images/20230531/c13d7e66dc7a457faf4b51e981d0aa68.png