Kernel Exploring
  • 前言
  • 支持
  • 老司机带你探索内核编译系统
    • 编译出你的第一个内核
    • 内核编译中的小目标
    • 可能是kbuild中最直接的小目标 – help
    • 使用了一个kbuild函数的目标 – cscope
    • 内核中单个.o文件的编译过程
    • 根目录vmlinux的编译过程
    • 启动镜像bzImage的前世今生
    • setup.bin的诞生记
    • 真假vmlinux–由vmlinux.bin揭开的秘密
    • bzImage的全貌
    • kbuild系统浅析
  • 启动时的小秘密
    • INIT_CALLS的秘密
    • 内核参数
  • 内核加载全流程
    • bootloader如何加载bzImage
    • 内核压缩与解压
    • 内核加载的几个阶段
    • 保护模式内核代码赏析
  • 内存管理
    • 内核页表成长记
      • 未解压时的内核页表
      • 内核早期的页表
      • cleanup_highmap之后的页表
      • 映射完整物理地址
      • 启用init_level4_pgt
    • 自底而上话内存
      • e820从硬件获取内存分布
      • 原始内存分配器--memblock
      • 页分配器
        • 寻找页结构体的位置
        • 眼花的页结构体
        • Node-Zone-Page
        • 传说的伙伴系统
        • Compound Page
        • GFP的功效
        • 页分配器的用户们
      • slub分配器
        • slub的理念
        • 图解slub
      • 内存管理的不同粒度
      • 挑战和进化
        • 扩展性的设计和实现
        • 减少竞争 per_cpu_pageset
        • 海量内存
        • 延迟初始化
        • 内存热插拔
        • 连续内存分配器
    • 虚拟内存空间
      • 页表和缺页中断
      • 虚拟地址空间的管家--vma
      • 匿名反向映射的前世今生
      • 图解匿名反向映射
      • THP和mapcount之间的恩恩怨怨
      • 透明大页的玄机
      • NUMA策略
      • numa balance
      • 老版vma
    • 内存的回收再利用
      • 水线
      • Big Picture
      • 手动触发回收
      • Page Fram Reclaim Algorithm
      • swapfile原理使用和演进
    • 内存隔离
      • memcg初始化
      • 限制memcg大小
      • 对memcg记账
    • 通用
      • 常用全局变量
      • 常用转换
    • 测试
      • 功能测试
      • 性能测试
  • 中断和异常
    • 从IDT开始
    • 中断?异常?有什么区别
    • 系统调用的实现
    • 异常向量表的设置
    • 中断向量和中断函数
    • APIC
    • 时钟中断
    • 软中断
    • 中断、软中断、抢占和多处理器
  • 设备模型
    • 总线
    • 驱动
    • 设备
    • 绑定
  • nvdimm初探
    • 使用手册
    • 上帝视角
    • nvdimm_bus
    • nvdimm
    • nd_region
    • nd_namespace_X
    • nd_dax
      • dev_dax
  • KVM
    • 内存虚拟化
      • Qemu内存模型
      • KVM内存管理
  • cgroup
    • 使用cgroup控制进程cpu和内存
    • cgroup文件系统
    • cgroup层次结构
    • cgroup和进程的关联
    • cgroup数据统计
  • 同步机制
    • 内存屏障
    • RCU
  • Trace/Profie/Debug
    • ftrace的使用
    • 探秘ftrace
    • 内核热补丁的黑科技
    • eBPF初探
    • TraceEvent
    • Drgn
  • 内核中的数据结构
    • 双链表
    • 优先级队列
    • 哈希表
    • xarray
    • B树
    • Maple Tree
    • Interval Tree
  • Tools
  • Good To Read
    • 内核自带文档
    • 内存相关
    • 下载社区邮件
Powered by GitBook
On this page
  • rstat结构
  • 如何更新
  • 更新顺序
  1. cgroup

cgroup数据统计

既然要管理系统的资源使用,那就需要有方法来统计资源使用。为此cgroup在当前内核版本(v5.16),采用了rstat的结构来统计。

rstat结构

在每个基础cgroup中有一组结构体用来记录状态变化,这组结构体统称为rstat。这组结构体长这个样子:

    +======================================+
    |bstat                                 |
    |last_bstat                            |
    |    (struct cgroup_base_stat)         |
    |                                      |
    |rstat_cpu                             |
    |    (struct cgroup_rstat_cpu* _percpu)|
    |    +---------------------------------+
    |    |updated_children                 |
    |    |updated_next                     |
    |    |    (struct cgroup*)             |
    |    |                                 |
    |    |bsync                            |
    |    |    (struct u64_stats_sync)      |
    |    |     +---------------------------+
    |    |     |seq                        |
    |    |     |    (seqcount_t)           |
    |    |     +---------------------------+
    |    |bstat                            |
    |    |last_bstat                       |
    |    |     (struct cgroup_base_stat)   |
    |    |     +---------------------------+
    |    |     |cputime                    |
    |    |     |    (struct task_cputime)  |
    |    |     |    +----------------------+
    |    |     |    |stime                 |
    |    |     |    |utime                 |
    |    |     |    |    (u64)             |
    |    |     |    |sum_exec_runtime      |
    |    |     |    |    (unsigned long)   |
    |    |     +----+----------------------+
    |    +---------------------------------+
    |                                      |
    +======================================+

其中最主要的有两部分:

  • cgroup_base_stat 用来记录数据

  • updated_children/updated_next 用来记录谁需要更新

如何更新

当整个cgroup树形结构增加时,如何避免不必要的统计动作,成了系统优化需要考虑的问题。对rstat来讲,updated_children/updated_next就是起到这个作用的。

参与这个工作主要有两个函数:

  • cgroup_rstat_updated

  • cgroup_rstat_cpu_pop_updated

第一个是添加,第二个是删除。

话不多说,咱来看看效果图。

假设最开始cgrp1并没有数据改变

                                  cgroup_root
                                  +------------------+<------------------------------+
                                  |                  |                               |
                                  |updated_children--|---+                           |
                                  +------------------+   |                           |
                                                         |                           |
                               +-------------------------+                           |
                               |                                                     |
                               |                                                     |
       cgrp1                   |  cgrp2                      cgrp3                   |
       +------------------+    +->+------------------+<----+ +------------------+    |
       |updated_next      |       |updated_next   ---|------>|updated_next   ---|----+
       |updated_children  |       |updated_children--|--+  | |updated_children  |
       +------------------+       +------------------+  |  | +------------------+
                                                        |  |
                               +------------------------+  |
                               |                           |
                               |  cgrp2'                   |
                               +->+------------------+     |
                                  |updated_next    --|-----+
                                  |updated_children  |
                                  +------------------+

cgrp1中数据有改变之后,cgrp1也会加入到这个链表中。

                                  cgroup_root
                                  +------------------+<------------------------------+
                                  |                  |                               |
                                  |updated_children--|---+                           |
                                  +------------------+   |                           |
                                                         |                           |
    +----------------------------------------------------+                           |
    |                                                                                |
    |                                                                                |
    |  cgrp1                      cgrp2                      cgrp3                   |
    +->+------------------+       +------------------+<----+ +------------------+    |
       |updated_next   ---|------>|updated_next   ---|------>|updated_next   ---|----+
       |updated_children  |       |updated_children--|--+  | |updated_children  |
       +------------------+       +------------------+  |  | +------------------+
                                                        |  |
                               +------------------------+  |
                               |                           |
                               |  cgrp2'                   |
                               +->+------------------+     |
                                  |updated_next    --|-----+
                                  |updated_children  |
                                  +------------------+

所以说白了, updated_children/updated_next还是一种树形结构。其中只把有状态更新和需要更新的节点包含了进来。

更新顺序

多说一句,cgroup_rstat_cpu_pop_updated这个函数还是挺有意思的。因为cgroup的树形结构的要求,子节点的状态需要汇总到父节点,所以更新的时候就要求从子节点更新,这样才能让父节点得到正确的统计。

Previouscgroup和进程的关联Next同步机制

Last updated 1 year ago