首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

内核启动时为什么要做线性映射?

10年以上工作经验,主要从事系统软件开发,涵盖:系统库开发、指令集优化、Linux内核开发等。累计为某些开源社贡献过一定数量的patch。...在 Linux 内核启动之后,对于 32 位的系统来说,他会把 0 ~ 896M 这部分低端内存(low memory)都做线性映射,不管这部分内存是否需要用到。...注意:linux内核虽然在开机的时候,映射了(对于64为平台来说)所有物理内存,但是他并没占有这些内存,只是为了访问方便。 以下代码来自于:linux-5.15,ARM64架构。...注意,对于一个典型ARM64 Linux架构来说,pte能映射2^9*4K = 2M地址空间。...注意,对于一个典型ARM64 Linux架构来说,pmd能映射2^9*2M = 1G地址空间。

73710
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    Linux 内核】实时调度类 ⑥ ( 实时调度类核心函数源码分析 | 插入进程到执行队列 | 从执行队列中选择优先级最高的进程 )

    内核源码的 linux-5.6.18\kernel\sched\rt.c 源文件中定义 , 实时调度 相关的 核心函数 也定义在该源码中 ; 一、enqueue_task_rt 函数 ( 插入进程到执行队列...task_current(rq, p) && p->nr_cpus_allowed > 1) enqueue_pushable_task(rq, p); } 源码路径 : linux-5.6.18\...)) return NULL; p = _pick_next_task_rt(rq); set_next_task_rt(rq, p, true); return p; } 源码路径 : linux...sched_rt_entity *rt_se; struct rt_rq *rt_rq = &rq->rt; do { rt_se = pick_next_rt_entity(rq, rt_rq); BUG_ON...sched_rt_entity *next = NULL; struct list_head *queue; int idx; idx = sched_find_first_bit(array->bitmap); BUG_ON

    53310

    解析Linux中的VFS文件系统之文件系统的注册(二)

    比如在笔者的 Linux 机器下就注册有 "rootfs"、"proc"、"ext2"、"sockfs" 等十几种文件系统。...3.1 文件系统的数据结构 在 Linux 源代码中,每种实际的文件系统用以下的数据结构表示(include/linux/fs.h): 1 struct file_system_type { 2...--  3.2 注册 rootfs 文件系统  在众多的实际文件系统中,之所以单独介绍 rootfs 文件系统的注册过程,实在是因为该文件系统 VFS 的关系太过密切,如果说 ext2/ext3 是 Linux...宏的声明及 arch\i386\vmlinux.lds 文件来理解这一过程),但是 rootfs 的注册却是通过 init_rootfs() 这一初始化函数来完成,这意味着 rootfs 的注册过程是 Linux...struct file_system_type * fs) 2 { 3 int res = 0; 4 struct file_system_type ** p; 5 6 BUG_ON

    2K60

    深入理解 kernel panic 的流程

    ] oops_end, 1, 11 [ 4.354740] -(2)[1:swapper/0]Kernel panic - not syncing: Fatal exception 这是linux...有过驱动调试经验的人肯定都知道这个东西,这里的BUG跟我们一般认为的“软件缺陷”可不是一回事,这里说的BUG()其实是linux kernel中用于拦截内核程序超出预期的行为,属于软件主动汇报异常的一种机制...BUG()跟BUG_ON(1)其实本质是一回事,后者只是在前者的基础上做了简单的封装而已,BUG()的实现 本质是埋入一条未定义指令:0xe7f001f2,触发ARM发起Undefined Instruction...) sig = 0; oops_end(flags, regs, sig); } 总流程大致如下: 通常来说,代码分析过程结合kernel log一起看会理解来得更加深刻,如果是BUG()/BUG_ON...例如: 从上面log知PC死在的地址,通过add2Line工具结合内核符号映射表 vmlinux 就可以定位出具体代码所在文件行号: arm-linux-androideabi-addr2line -e

    2K32

    深入 kernel panic 流程【转】

    0] oops_end, 1, 11 [ 4.354740] -(2)[1:swapper/0]Kernel panic - not syncing: Fatal exception 这是linux...有过驱动调试经验的人肯定都知道这个东西,这里的BUG跟我们一般认为的“软件缺陷”可不是一回事,这里说的BUG()其实是linux kernel中用于拦截内核程序超出预期的行为,属于软件主动汇报异常的一种机制...BUG()跟BUG_ON(1)其实本质是一回事,后者只是在前者的基础上做了简单的封装而已,BUG()的实现 本质是埋入一条未定义指令:0xe7f001f2,触发ARM发起Undefined Instruction...(1)那么内核一定会挂掉重启,而__WARN()只会dump_stack()而不会死机, 从源码跟log信息也可以容易区分两种情况,如果是BUG()/BUG_ON(1)的话一定有类似下面的log输出,只要搜索关键字...例如: 从上面log知PC死在的地址,通过add2Line工具结合内核符号映射表 vmlinux 就可以定位出具体代码所在文件行号: arm-linux-androideabi-addr2line

    4.8K21
    领券