- 主题:CPU能否为操作系统优化呢？
我现在的理解是context switch很慢。比如一个进程调用一个功能，如果是宏内核，就是一个调用，几个时钟。如果是进程,据说是50-80个时钟。
可不可以多个CPU核心，有一个专门负责这个功能的。但是如果有多个客户来调用，那还是得等，比同一个CPU核心进行context switch还慢。
context switch到底什么原因慢呢？是需要存储的东西太多了吗？
【 在 yangtou 的大作中提到: 】
: 微内核增加了额外的ipc开销，ipc需要context switch
:
: #发自zSMTH@NOP-AN00
--
FROM 98.42.143.*
CPU 内部的超线程就是 context switch，内部有多套寄存器相互切换。如果 CPU 能够把这个功能暴露出来给操作系统，而不是由 CPU 自动切换，那么你说的加速就有了。
【 在 bihai 的大作中提到: 】
: 我现在的理解是context switch很慢。比如一个进程调用一个功能，如果是宏内核，就是一个调用，几个时钟。如果是进程,据说是50-80个时钟。
: 可不可以多个CPU核心，有一个专门负责这个功能的。但是如果有多个客户来调用，那还是得等，比同一个CPU核心进行context switch还慢。
: context switch到底什么原因慢呢？是需要存储的东西太多了吗？
: ...................
--
FROM 47.243.39.*
是多余的ipc和context switch，多了的东西，优化不掉，优化掉就是宏内核了，那还折腾什么。
至于慢不慢，context switch是不可能比乘法指令快的。宏内核的内核也是跑在多个核上的，跑在一个核上岂不是更慢？
【 在 bihai 的大作中提到: 】
: 我现在的理解是context switch很慢。比如一个进程调用一个功能，如果是宏内核，就是一个调用，几个时钟。如果是进程,据说是50-80个时钟。
:
: 可不可以多个CPU核心，有一个专门负责这个功能的。但是如果有多个客户来调用，那还是得等，比同一个CPU核心进行context switch还慢。
: ...................
--来自微微水木3.5.12
--
FROM 116.224.249.*
操作系统的context和cpu线程没啥关系吧，又不是只关联几个通用寄存器和PC。再说了，一个核一个线程还不跑了？
【 在 hgoldfish 的大作中提到: 】
: CPU 内部的超线程就是 context switch，内部有多套寄存器相互切换。如果 CPU 能够把这个功能暴露出来给操作系统，而不是由 CPU 自动切换，那么你说的加速就有了。
:
: 【 在 bihai 的大作中提到: 】
: ...................
--来自微微水木3.5.12
--
FROM 116.224.249.*
如果暴露出来当然得改 CPU 设计了。
按我说的设计的话，CPU 在操作系统看来会有无限多个核心。所谓调度线程，在操作系统看来，不过是把一个 CPU 核心标志为运行和暂停，不用保存寄存器，每次切换都可以省下大量的 CPU 时钟周期。
【 在 yangtou 的大作中提到: 】
: 操作系统的context和cpu线程没啥关系吧，又不是只关联几个通用寄存器和PC。再说了，一个核一个线程还不跑了？
: --来自微微水木3.5.12
--
FROM 140.224.34.*
wild的想法，你看来要把线程context保存在芯片里面了，那还要不要超标量乱序执行了，流水线状态也一起保存吗？那你准备支持几个线程呢，准备为此还有调度逻辑等花费多少面积，这cpu能跑到多高频率？如果保存到ram里面？那好了，我们就差不多回到了软件context switch了。
再者，为了context信息已经花费这么多了，干嘛还要运行和暂停，一直并行运行不好吗，那这不就是现在cpu的多线程嘛。
【 在 hgoldfish 的大作中提到: 】
: 如果暴露出来当然得改 CPU 设计了。
:
: 按我说的设计的话，CPU 在操作系统看来会有无限多个核心。所谓调度线程，在操作系统看来，不过是把一个 CPU 核心标志为运行和暂停，不用保存寄存器，每次切换都可以省下大量的 CPU 时钟周期。
: ...................
--来自微微水木3.5.12
--
FROM 116.224.249.*
没错啊。CPU 直接模拟成无限核心。操作系统只管往 CPU 里面调度线程。
但是线程碰到文件 IO，或者两个线程进入临界区，它得暂停线程的执行，这也没错。这时候操作系统给 CPU 一个特别的指令什么的暂停执行，检测某个寄存器位才继续。
【 在 yangtou 的大作中提到: 】
: wild的想法，你看来要把线程context保存在芯片里面了，那还要不要超标量乱序执行了，流水线状态也一起保存吗？那你准备支持几个线程呢，准备为此还有调度逻辑等花费多少面积，这cpu能跑到多高频率？如果保存到ram里面？那好了，我们就差不多回到了软件context switch了。
: 再者，为了context信息已经花费这么多了，干嘛还要运行和暂停，一直并行运行不好吗，那这不就是现在cpu的多线程嘛。
: --来自微微水木3.5.12
: ...................
--
FROM 47.243.39.*
我说的不是很清楚，这个vm指的是解释型角本语言的jit，比如js的K8，也包括没jit的解释器。
也就是石更件搞搞优化，把js,lisp之类的跑快点。
【 在 dighole 的大作中提到: 】
: intel 的VT-X不就是干这个的吗
: --
发自「今日水木 on PBCM10」
--
FROM 117.147.20.*
MIPS Multi-threading extention
【 在 yangtou 的大作中提到: 】
: wild的想法，你看来要把线程context保存在芯片里面了，那还要不要超标量乱序执行了，流水线状态也一起保存吗？那你准备支持几个线程呢，准备为此还有调度逻辑等花费多少面积，这cpu能跑到多高频率？如果保存到ram里面？那好了，我们就差不多回到了软件context switch了。
: 再者，为了context信息已经花费这么多了，干嘛还要运行和暂停，一直并行运行不好吗，那这不就是现在cpu的多线程嘛。
: --来自微微水木3.5.12
: ...................
--
FROM 183.193.60.*
有什么特别之处吗，这不就是现在普遍的多线程吗？
【 在 rockyzhang 的大作中提到: 】
: MIPS Multi-threading extention
: 【 在 yangtou 的大作中提到: 】
: : wild的想法，你看来要把线程context保存在芯片里面了，那还要不要超标量乱序执行了，流水线状态也一起保存吗？那你准备支持几个线程呢，准备为此还有调度逻辑等花费多少面积，这cpu能跑到多高频率？如果保存到ram里面？那好了，我们就差不多回到了软件context switch了。
: ...................
--来自微微水木3.5.12
--
FROM 116.224.249.*