操作系统页表&进程调度Tips

本文说两个关于时间和空间的小Tips,即CPU和内存这一对冤家…近期爆出的CVE-2019-11478竟然让这一对冤家握手言和一起做恶…详见:
https://blog.csdn.net/dog250/article/details/94654620

不说TCP了,接下来说说页表和进程调度,这可是现代操作系统的核心之核心。

页表

  1. 但凡可以索引的,就一定可以转换为查找,时间换空间。
  2. 但凡可以查找的,就一定可以转换为索引,空间换时间。
  3. 分级页表索引表占用内存比较多,但在32位系统还不算太多,所以可以使用。
  4. 分级页表索引表占用内存比较多,但在64位系统非稀疏地址结构下,也不太多,所以可以使用。
  5. 分级页表索引占用内存比较多,在64位系统稀疏地址结构情况下,将不可用。
  6. 分级页表索引全部虚拟地址映射的话,级数越多,越消耗内存,级数增加的意义在于索引稀疏地址空间有好处。

由于系统中所有的进程共享同一个物理内存空间,可以想象,由于地址空间的隔离性,每一个物理页面基本上都是属于一个进程的,那么虚拟页面向物理页面的映射就可以转换为 逐个物理页面遍历询问“你是不是已经被分配给了我?” 这样的问题。

但是物理地址空间虽然没有虚拟地址空间大,但是也不小,逐个遍历将不现实,于是,常规哈希便是立即的解决方案。即先将虚拟地址连同其进程ID哈希到一个较小的物理地址空间,然后遍历这个较小的空间即可。

考虑到页面的共享,比如Glibc这种,所谓的 冲突链表 将会有两类,即 哈希冲突共享冲突

于是,一个合理的上述类型的页表就是下面的样子:
在这里插入图片描述

这就是反置页表,注意,系统中只有一张表,超级节省内存。性能取决于哈希算法性能以及同步互斥。

核心思想就是 索引一定能改成查找。

进程调度

在早期,UNIX进程调度策略五花八门,各种算法,但是那个时代已经过去了,现在是多核心时代,有更重要的事情需要关注,而不是调度策略。

在早期的单CPU时代,所有的进程都要在这唯一的CPU上排队串行,所以公平性效率就完全取决于调度算法。比如长进程不能饿死短进程,短进程要尽快结束等等。

现如今到了多核心时代,由于存在多个执行核心,调度的重点转换为了 为进程/线程寻找最合适的处理核心。 而不再是 为进程/线程选择最合适的执行时间。

那么,嵌套的问题便是,对于单独的一个处理核心,还需不需要 为进程/线程选择最合适的执行时间。 答案是需要,但是并不再重要。因为存在多个处理核心,进程/线程便不会憋住,大不了去别的处理核心呗。

那么,多核心时代,需要关注什么?

注意,多核心和多CPU并不是一个概念,稍微有区别,多核心结构中必要的东西就是缓存架构,而缓存的架构决定了进程/线程在处理核心之间的迁移,而这个正是调度的核心算法之一。

在不过度饥饿的情况下,能不迁移进程/线程就不迁移,这会提高缓存的利用率。

其次,对于单独的处理核心,我们会发现,不管是Windows NT 4.0+,还是Linux 2.6/3.x/4.x/5.x,或者FreeBSD,各种UNIX变体,千篇一律的都是类似Linux 2.6的 O ( 1 ) O(1) O(1)算法,即便Linux新的CFS也不例外:

  1. 动态优先级调整。
  2. 惩罚计算型任务,奖励IO型任务。

对于单独的一个核心,以上的技术显得成熟且足够,然而多核心之间的进程/线程迁移却还不尽人意,还有很长的路要走。参见下面的链接:
The Linux Scheduler: a Decade of Wasted Cores
原文如下:
http://www.ece.ubc.ca/~sasha/papers/eurosys16-final29.pdf

之所以会是如此糟糕,在我看来在于设计的思路,人们依然循着古老的思路做调度算法的设计,即在一个单独的处理核心上,希望找出一个最佳的时机调度一个最合适的进程/线程。

但是正相反,我觉得这并不是一个时间维度的算法,而是转换成了一个空间维度的算法,类似于内存分配的问题,而不是CPU时间分配的问题。

是的,多核心调度,类似于设计一个高效率的内存分配算法,无碎片(无忙无闲),缓存利用率高。


━━━●━━━─皮鞋湿─不会胖── 2:07
⇆ ㅤㅤ◁                       ❚❚                           ▷ ㅤㅤ

浙江温州皮鞋湿,下雨进水不会胖!!

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值