t*****s
发帖数: 416 | 1 首先，对挖了个坑在本区引战向所有搞web的人道歉，小菊花和赵C除外。有兴趣八为啥
他俩除外的可以翻一翻吵架的那几个帖子，自己判断是非，觉得我不对过去帮着他们骂
我也无所谓。但是请不要在这个贴里歪楼。
我本意是说web虽然职位多，但是竞争压力也大。从来没有过任何贬低web技术含量或者
领域前景的意思——事实上也没有任何沾边的言论。如果引起了误解，表示歉意。
因为我挖完坑很没节操的没把自己埋里面就跑了，小菊花同学开始连续开贴钓鱼并且在
本区追着我黑系统这个领域。这不，刚刚又新开了个定向钓鱼贴明里暗里指着说我学艺
不精。
其实黑我倒无所谓，不过小菊花同学黑我不过瘾又把整个系统领域给打上了“简单机械
重复劳动”的标签，未免会给对系统感兴趣的同学们产生一些不好的印象。考虑到小菊
花同学如此愤恨系统领域是由我引起的，我不免觉得对这种负面印象负有一定的连带责
任，所以写这个帖子。以一个“学艺不精”的系统软件工程师的视角，来讲讲系统这块
领域到底是怎么样的。
小菊花同学是旗帜鲜明的系统黑，我是立场坚定的系统pro，所以都不免带有bias，大
家可以把这个帖子和小菊花同学的帖子对照阅读，通过自己的思考来得出结论。
To 小菊花同学：
之所以开新帖没有回您的钓鱼贴，就是因为吵架吵烦了。虽然您的钓鱼贴里含沙射影很
是黑了我一番，不过我可以保证这里没有夹任何反唇相讥的私货，所以也麻烦您leave
me alone。OK?
-------------------
虽然大家上课都学过，但是既然要掉书袋，自然不免从定义掉起——什么是系统？
首先系统是一个抽象层，将所有和硬件交互的细节埋在统一的API下，作为一个复用结
构减少应用程序员的工作的同时提供portability。
其次，系统是一套服务，它实现和维护硬件本身没有提供而应用层又必不可少的功能，
比如多进程、线程、虚拟化、网络栈、文件系统等等，将这些必须的功能同样通过一套
统一的API提供给应用层程序员。
因此对于应用层程序员来说，他们编程的目标不是一套真实的硬件计算机，而是一台抽
象化的虚拟机，这个虚拟机就是系统。所以从一定程度上来讲，JVM也是一个系统。只
不过目前这个系统的具体实现大多都依赖于原生操作系统。如果有一天，有人直接在硬
件层上方实现了JVM，那么这个JVM也就成为了一个传统意义上的系统——当然，那时候我
们多半就会叫它JOS了。
既然应用层的编程对象是系统这个虚拟机，那么就很容易发现，应用程序的快慢，是受
到系统速度的限制的。如果系统的效率很低，那么很可能应用程序在使用分配内存、读
写文件、进程切换这些系统服务的时候浪费大量的时间。这样的话，无论应用程序本身
使用的算法多么优秀和效率，依然都不会速度太快。
现在系统通过多年发展，主流系统的大部分服务效率都已经达到了很优化的程度。但是
受到计算机构架和硬件速度的影响，许多系统服务的速度和应用程序在CPU上执行的速
度比起来依然很慢。这时候，应用程序员可能有多种选择，一是优化代码，减少调用低
速系统服务的次数，二是使用异步版本的系统服务。
然而，仅仅是正确意识到在哪些系统服务上需要考虑系统服务的效率问题，就要求应用
程序员对系统有着基本的了解，更不要说正确作出相应的优化选择了。有些系统比如
JVM在这个问题上可能会替应用程序员作出一定的优化。但是有些系统服务，比如I/O，
仍然需要程序员自己根据具体情况作出相应的优化选择。
所以这是本文的第一个point——不只有系统程序员需要了解系统。
既然提到了效率，那么就不免联想到profiling。书袋我就不掉了。应用程序会存在瓶
颈，系统当然也会。所以系统设计的重要原则之一就是trade off——多使用一些富裕
的硬件资源，减少稀缺/缓慢硬件资源的负荷，从而达到整体系统速度优化的目的。比
如说文件访问，操作系统就会在内存里创建一片很不小的cache，用内存容量来交换低
速文件I/O的负荷。
然而这又产生了一个问题——什么是富裕的硬件资源？和软件相似，硬件的各个领域并
不是匀速发展的。从PC崛起时的80286到今天的i7，CPU仅仅是时钟频率就增加了200倍
，算上流水结构和多核的话实际性能可能相差上万倍。然而硬盘的传输率上升了多少呢
？不到一百倍。这就意味着，当年对于12.5MHz的286来说速度太快的5Mb/s的硬盘，现
在已经是太慢太慢了。那么30年前设计的磁盘I/O调度是否还一定是一个优化的设计呢
？很可能已经不是了。
这个问题其实反应了系统设计的一个根本问题——系统和硬件是深度耦合的。每一次硬
件构架的革命，同样也会带来系统设计的革命。而一个常用硬件的性能发生巨大的变化
，也会给系统设计带来较大的调整。太早的就不说了，03年64位处理器的发布，05年多
核的出现，07年虚拟化的兴起，都给系统的领域带来了很大的冲击。这两年SSD和flash
的流行，也给文件系统领域带来了很大的变革。
因此，本文的第二个point是——系统领域从来不缺创新，只要硬件在进化，系统也一
定在进化。
那么下一步的系统创新在哪里呢？本人入行不久，斗胆卖弄一二做些大胆猜测。
CPU：
两U融合其实已经喊了很久，因为种种非技术原因一直没有作出实质性进展，PC市场整
体衰落的今天大概Intel也不会再有动力给x86做构架革命。CPU和GPU由于各自的构架的
优劣，在现代计算领域里都有难以相互替代的位置。x86时代，GPU一直是以从设备的角
色出现在整个构架体系里，在数据传输，任务调度上都有着很大的限制，即使到了GPU
和CPU进入同一块芯片之后也没有根本性的改变。OpenGL和OpenCL这两个标准的实现也
几乎是完全通过GPU的驱动来进行工作。然而这种实现模式导致这两个库对于应用层程
序员来说还是太过复杂，特别是OpenCL，需要对GPU的构架和硬件原理有着比较清楚的
理解才可以正确使用。
在GPU的应用场景越来越广泛的今天，Qualcomm等SOC vender很可能会考虑将GPU和CPU
在系统总线上提升到平等的host位置进行交互，实现真正的两U构架。而相应的对GPU任
务的调度和数据管理就可以通过系统来直接实现，让应用层程序员专注于应用逻辑实现
。内核任务也可以直接在GPU上运行。这将给系统的核心——内存管理和进程体系带来
彻底的革命。
Network:
Google Fiber目前还在试水阶段，但是大家都清楚光纤入户的背后隐藏这Google尚未为
人知的巨大野心。一旦光纤入户成为常态，那么网络设备的传输率将会有一个质的飞跃
。这不仅可能在网络协议栈上带来巨大的变化，而且还可能涉及网络设备在整个系统里
的地位的改变。
另一方面，移动设备正式方兴未艾之时。移动设备的两个核心需求connectivity和待机
时间已经产生了巨大的矛盾。在目前硬件和网络协议体系下，保持connectivity基本上
意味着额外的耗电量和牺牲待机时间。如果电池容量问题不能出现质的突破的话，那么
唯一的解决方案就是对硬件和网络协议栈进行修改。
Storage:
SSD的流行让存储设备的传输率向前迈了一大步。但最关键的是它让存储设备的响应时
间提高了3-4个数量级。这就意味着二级寻址的overhead已经不再是可以忽略的了。记
得进入64位时代之后我们那大把大把用不掉的地址空间么？Storage进入地址空间直接
寻址一定是未来的一个趋势。如果未来存储设备的传输率继续提高，那么Storage和
Memory之间的界限将会变得模糊，整个系统构架也会随之剧变。
File system：
文件系统的革新其实随着储存设备的更新换代以及infrastructure的更新一直在进行。
大家搜一搜file system的职位就可以有一个很清楚的认识。我对这部分最新的情况了
解的程度一般，就不瞎说了。 |
r*********r
发帖数: 3195 | 2 系统方面没什么新书是个问题。
70年代的 John Lions, 80年代的 Maurice Bach 之后就没出过什么算得上经典的书。
让人觉得这个领域没什么新的激动人心的东西。 |
x****u
发帖数: 44466 | 3 你这个同学对CS的认识，除了几个机械劳动的领域外，剩下的全都是些文学性，抒情的
东西。
把最后那一段每个奇怪的念头拿出来单发一贴，咱们可以讨论一下为什么不靠谱。
【在 t*****s 的大作中提到】
: 首先，对挖了个坑在本区引战向所有搞web的人道歉，小菊花和赵C除外。有兴趣八为啥
: 他俩除外的可以翻一翻吵架的那几个帖子，自己判断是非，觉得我不对过去帮着他们骂
: 我也无所谓。但是请不要在这个贴里歪楼。
: 我本意是说web虽然职位多，但是竞争压力也大。从来没有过任何贬低web技术含量或者
: 领域前景的意思——事实上也没有任何沾边的言论。如果引起了误解，表示歉意。
: 因为我挖完坑很没节操的没把自己埋里面就跑了，小菊花同学开始连续开贴钓鱼并且在
: 本区追着我黑系统这个领域。这不，刚刚又新开了个定向钓鱼贴明里暗里指着说我学艺
: 不精。
: 其实黑我倒无所谓，不过小菊花同学黑我不过瘾又把整个系统领域给打上了“简单机械
: 重复劳动”的标签，未免会给对系统感兴趣的同学们产生一些不好的印象。考虑到小菊
|
H**r
发帖数: 10015 | |
x****u
发帖数: 44466 | 5 真是入行不久想法爆棚，我就挨条谈谈为什么不靠谱吧：
GPU归根结底就是DSP，而CPU就是通用DSP。如果上体系结构课没睡觉的话，就应该知道
为了实现现代CPU的“通用”二字，在IC效率上，设计复杂度上要付出什么代价。想让
GPU编程和CPU编程一样简单通用当然没问题，但这样就等于把GPU改造成了CPU。不是说
一个芯片名称挂上GPU几字后就天然的速度快的。
GPU |
x****u
发帖数: 44466 | 6 这事稍微动动脑子就知道没那么难。有运营商配合，把后台更新放在server端，然后用
特定SMS唤醒设备即可。只收短信待机一个月的东西N年前就有了。
现在之所以让你在设备上跑网络应用，归根结底还是商业决策，为了吃光3G流量而已。 |
x****u
发帖数: 44466 | 7 唉，有这个想法真是计死早了。
首先x86-64的硬件支持地址根本就不到64位，OS支持的比硬件支持的位数还少。原因是
CPU支持大地址是有巨大代价的。
另外没学过南桥北桥么？统不统一寻址其实意义不大，关键是速度快和慢的设备不可以
连在一起。就算表面是统一寻址的ROM，在系统实现里也是和RAM分离连接的。 |
x****u
发帖数: 44466 | 8 基本就是王垠翻版，认为内核比用户态快，CPU比内核快。所以想提高速度应该尽可能
的把东西放到下层。
候我 |
x****u
发帖数: 44466 | 9 硬盘对于286/386来说一点也不快啊，当时因为内存贵cache小，启动一个Win16小程序
读半分钟盘是家常便饭。
硬盘速度主要慢在磁头频繁移动上，前面建议过你了，用process monitor抓一抓OS的
磁盘log，看看读写都发生在什么地方，OS是怎么解决此问题的。
flash |
z****e
发帖数: 54598 | 10 给你小提醒一下
the network is the computer
现在最大的latency并不来自computer内部，而在于network
结了 |
|
|
g*****g
发帖数: 34805 | 11 这个东西我很清楚，曾经给一startup干就做这个。大约可以节省30%的流量，
但是有很多用户隐私方面的问题，特别是https的东西，如果不用man-in-the-middle-
attack，
没法做，如果用，安全上有隐患。
【在 x****u 的大作中提到】
: 这事稍微动动脑子就知道没那么难。有运营商配合，把后台更新放在server端，然后用
: 特定SMS唤醒设备即可。只收短信待机一个月的东西N年前就有了。
: 现在之所以让你在设备上跑网络应用，归根结底还是商业决策，为了吃光3G流量而已。
|
a****l
发帖数: 8211 | 12 网络的问题不是技术问题，而是商业问题政策问题，wsn完全没有办法解决这种问题。
就好比说普遍的一毛钱一个短信的问题，你要是从技术角度看搞个什么短信的调度算法
以为能降低收费就搞笑了。
【在 z****e 的大作中提到】
: 给你小提醒一下
: the network is the computer
: 现在最大的latency并不来自computer内部，而在于network
: 结了
|
t*****s
发帖数: 416 | 13 我真佩服你这个不要脸的脾性。
那边黑了我我没理你。这边明说了不欢迎你还要硬凑上来非要战一场。
来来来，要战就战，还真以为你们耍流氓就无敌了？
“机械劳动”不够，“文学抒情”又出来了。有点干货没？那段是机械劳动哪段是文学
抒情？
当然啦跟某人那种证据放眼前都能睁眼说瞎话的范儿，您这编两个莫须有的tag还真不
算是个事儿。
【在 x****u 的大作中提到】
: 你这个同学对CS的认识，除了几个机械劳动的领域外，剩下的全都是些文学性，抒情的
: 东西。
: 把最后那一段每个奇怪的念头拿出来单发一贴，咱们可以讨论一下为什么不靠谱。
|
t*****s
发帖数: 416 | 14 总原则和基本原理自然是没有怎么变的。新技术里又有多少基础理论上个革新呢？
如果要说技术细节的话，系统不是没怎么变，而是变得太快了。
因为Linux现在成了事实上的工业标准。而Linux的更新速度导致，一本以linux为基础
的书必然在写完的时候就部分落后了。
虚拟化算不算新东西？07进入Linux内核。但是现在你几乎找不到虚拟化实现原理的书
，只有去读Linux的源代码。
【在 r*********r 的大作中提到】
: 系统方面没什么新书是个问题。
: 70年代的 John Lions, 80年代的 Maurice Bach 之后就没出过什么算得上经典的书。
: 让人觉得这个领域没什么新的激动人心的东西。
|
t*****s
发帖数: 416 | 15 一看就是基本没做过OpenGL和OpenCL应用，抱着不知道多少年前课上学的那点基础知识
大发厥词。
还GPU=DSP。lol您这是还活在上世纪九十年代呢吧。
你理解的GPU编程问题完全是compiler问题，早就都解决了。现在GPU编程的难点是数据
管理和进程调度，原因是GPU在系统构架里的位置而不是GPU的内部结构。
拜托您去补补基础知识再来评论吧。还真当硬件和系统20年没变过了？
【在 x****u 的大作中提到】
: 真是入行不久想法爆棚，我就挨条谈谈为什么不靠谱吧：
: GPU归根结底就是DSP，而CPU就是通用DSP。如果上体系结构课没睡觉的话，就应该知道
: 为了实现现代CPU的“通用”二字，在IC效率上，设计复杂度上要付出什么代价。想让
: GPU编程和CPU编程一样简单通用当然没问题，但这样就等于把GPU改造成了CPU。不是说
: 一个芯片名称挂上GPU几字后就天然的速度快的。
: GPU
|
t*****s
发帖数: 416 | 16 就你这点商业眼光还想搞startup？
通过SMS唤醒等于把设备和系统vender延长设备待机时间的责任转嫁到app开发者和运营
商身上。光用小拇指想想就知道后者不可能接受这种方案。那么设备和系统vender之间
的竞争必然导致这部分在底层作出改进。
【在 x****u 的大作中提到】
: 这事稍微动动脑子就知道没那么难。有运营商配合，把后台更新放在server端，然后用
: 特定SMS唤醒设备即可。只收短信待机一个月的东西N年前就有了。
: 现在之所以让你在设备上跑网络应用，归根结底还是商业决策，为了吃光3G流量而已。
|
g******n
发帖数: 253 | 17 谁给缩写一下。忒长了。
【在 t*****s 的大作中提到】
: 首先，对挖了个坑在本区引战向所有搞web的人道歉，小菊花和赵C除外。有兴趣八为啥
: 他俩除外的可以翻一翻吵架的那几个帖子，自己判断是非，觉得我不对过去帮着他们骂
: 我也无所谓。但是请不要在这个贴里歪楼。
: 我本意是说web虽然职位多，但是竞争压力也大。从来没有过任何贬低web技术含量或者
: 领域前景的意思——事实上也没有任何沾边的言论。如果引起了误解，表示歉意。
: 因为我挖完坑很没节操的没把自己埋里面就跑了，小菊花同学开始连续开贴钓鱼并且在
: 本区追着我黑系统这个领域。这不，刚刚又新开了个定向钓鱼贴明里暗里指着说我学艺
: 不精。
: 其实黑我倒无所谓，不过小菊花同学黑我不过瘾又把整个系统领域给打上了“简单机械
: 重复劳动”的标签，未免会给对系统感兴趣的同学们产生一些不好的印象。考虑到小菊
|
t*****s
发帖数: 416 | 18 x64现在就已经到48位了，换算过来是256TB。对于大多数应用措措有余了。主板支持根
本不过是一两个月就能搞出来的小变动。如果体系真的要发生这个变化的话根本不算个
事儿。
还南桥北桥，难怪你整天计死早计死早，感情就一直在吃学校里的老本。x86不知道哪
年就没北桥了。ARM平台上更是从来就没有过南桥北桥的说法。无论哪个平台，现在的
趋势都是减少总线级数，构架扁平化，提高集成度。
当然了您的计算机老师当年肯定没讲过这些嘛。
【在 x****u 的大作中提到】
: 唉，有这个想法真是计死早了。
: 首先x86-64的硬件支持地址根本就不到64位，OS支持的比硬件支持的位数还少。原因是
: CPU支持大地址是有巨大代价的。
: 另外没学过南桥北桥么？统不统一寻址其实意义不大，关键是速度快和慢的设备不可以
: 连在一起。就算表面是统一寻址的ROM，在系统实现里也是和RAM分离连接的。
|
t*****s
发帖数: 416 | 19 呵呵，言之无物了就开始学某人造观点了？
不要说我没说过这些“内核比用户态快，CPU比内核快。所以想提高速度应该尽可能的
把东西放到下层。”就算我说了跟王垠有一毛钱关系？
就你这种系统学的一知半解的才会拿快慢来衡量内核态和用户态的差别。内核态和用户
态都在同一个CPU上跑，区别只不过是内存访问权限而已，哪儿来的快慢。
“CPU比内核快”就更搞笑了，这两个东西也能放一起比快慢？您真的是学计算机的么。
【在 x****u 的大作中提到】
: 基本就是王垠翻版，认为内核比用户态快，CPU比内核快。所以想提高速度应该尽可能
: 的把东西放到下层。
: 候我
|
d*******r
发帖数: 3299 | |
|
|
t*****s
发帖数: 416 | 21 人家的目的不过是上下嘴皮子一张把我说的东西给说的一钱不值罢了。
你跟人家较真人家要恨你的。
【在 g*****g 的大作中提到】
: 这个东西我很清楚，曾经给一startup干就做这个。大约可以节省30%的流量，
: 但是有很多用户隐私方面的问题，特别是https的东西，如果不用man-in-the-middle-
: attack，
: 没法做，如果用，安全上有隐患。
|
x****u
发帖数: 44466 | 22 你回炉补补课吧。
还GPU进程调度，老师没告诉你实现这个东西需要什么硬件代价么？
【在 t*****s 的大作中提到】
: 一看就是基本没做过OpenGL和OpenCL应用，抱着不知道多少年前课上学的那点基础知识
: 大发厥词。
: 还GPU=DSP。lol您这是还活在上世纪九十年代呢吧。
: 你理解的GPU编程问题完全是compiler问题，早就都解决了。现在GPU编程的难点是数据
: 管理和进程调度，原因是GPU在系统构架里的位置而不是GPU的内部结构。
: 拜托您去补补基础知识再来评论吧。还真当硬件和系统20年没变过了？
|
x****u
发帖数: 44466 | 23 Re错人了，冷静。
【在 t*****s 的大作中提到】
: 就你这点商业眼光还想搞startup？
: 通过SMS唤醒等于把设备和系统vender延长设备待机时间的责任转嫁到app开发者和运营
: 商身上。光用小拇指想想就知道后者不可能接受这种方案。那么设备和系统vender之间
: 的竞争必然导致这部分在底层作出改进。
|
x****u
发帖数: 44466 | 24 你这小同学真是只会骂人但死也不读书啊。
自己设计一个类似系统，就知道为什么高速设备和低速是分开连的了。现在主板上几乎
所有功能都集中到一两个芯片里了，但这不是你放弃学习的理由。
【在 t*****s 的大作中提到】
: x64现在就已经到48位了，换算过来是256TB。对于大多数应用措措有余了。主板支持根
: 本不过是一两个月就能搞出来的小变动。如果体系真的要发生这个变化的话根本不算个
: 事儿。
: 还南桥北桥，难怪你整天计死早计死早，感情就一直在吃学校里的老本。x86不知道哪
: 年就没北桥了。ARM平台上更是从来就没有过南桥北桥的说法。无论哪个平台，现在的
: 趋势都是减少总线级数，构架扁平化，提高集成度。
: 当然了您的计算机老师当年肯定没讲过这些嘛。
|
x****u
发帖数: 44466 | 25 这算学过CS么？你们OS老师告诉你内核态和用户态只差在内存访问权限上？
内核态最大问题是无法有效的利用系统服务，你自己写个小东西就知道，大多数算法放
入内核肯定要牺牲系统效率。
当年物理这一行热门的时候，是不是不学微积分的也敢证明相对论错误？
么。
【在 t*****s 的大作中提到】
: 呵呵，言之无物了就开始学某人造观点了？
: 不要说我没说过这些“内核比用户态快，CPU比内核快。所以想提高速度应该尽可能的
: 把东西放到下层。”就算我说了跟王垠有一毛钱关系？
: 就你这种系统学的一知半解的才会拿快慢来衡量内核态和用户态的差别。内核态和用户
: 态都在同一个CPU上跑，区别只不过是内存访问权限而已，哪儿来的快慢。
: “CPU比内核快”就更搞笑了，这两个东西也能放一起比快慢？您真的是学计算机的么。
|
x****u
发帖数: 44466 | 26 又发现一个槽点：
内核态和用户态都在同一个CPU上跑，同学你真该补课了。。。
么。
【在 t*****s 的大作中提到】
: 呵呵，言之无物了就开始学某人造观点了？
: 不要说我没说过这些“内核比用户态快，CPU比内核快。所以想提高速度应该尽可能的
: 把东西放到下层。”就算我说了跟王垠有一毛钱关系？
: 就你这种系统学的一知半解的才会拿快慢来衡量内核态和用户态的差别。内核态和用户
: 态都在同一个CPU上跑，区别只不过是内存访问权限而已，哪儿来的快慢。
: “CPU比内核快”就更搞笑了，这两个东西也能放一起比快慢？您真的是学计算机的么。
|
x****u
发帖数: 44466 | 27 你这家伙真是对体系结构连个定性的认识都没有。
硬盘内存混合编址然后对CPU透明，技术上是毫无难度的，前面已经给你讲过了，硬盘
现在也是靠一个绝对地址读512xN字节块的。
问题是这么做是否有意义，是否合算。对于外行来说，可能觉得程序好写了。问题是你
们不看文档么？OS早就支持直接通过线性地址访问硬盘的，有个东西叫mmap啊亲。
CPU通过地址线直读硬盘的最大问题是，硬盘数据会占用CPU内部的cache，这是最快而
且最宝贵的资源。而硬盘就算是SSD也是远慢于内存的，不在中间插入一层相对低速但
是更大容量的cache，就是巨大的性能浪费。所以现在CPU别说硬盘，就连ROM都不直接
去读。
【在 t*****s 的大作中提到】
: x64现在就已经到48位了，换算过来是256TB。对于大多数应用措措有余了。主板支持根
: 本不过是一两个月就能搞出来的小变动。如果体系真的要发生这个变化的话根本不算个
: 事儿。
: 还南桥北桥，难怪你整天计死早计死早，感情就一直在吃学校里的老本。x86不知道哪
: 年就没北桥了。ARM平台上更是从来就没有过南桥北桥的说法。无论哪个平台，现在的
: 趋势都是减少总线级数，构架扁平化，提高集成度。
: 当然了您的计算机老师当年肯定没讲过这些嘛。
|
h****e
发帖数: 2125 | 28 现在谁用mmap读硬盘啊，都是读网卡吧。
【在 x****u 的大作中提到】
: 你这家伙真是对体系结构连个定性的认识都没有。
: 硬盘内存混合编址然后对CPU透明，技术上是毫无难度的，前面已经给你讲过了，硬盘
: 现在也是靠一个绝对地址读512xN字节块的。
: 问题是这么做是否有意义，是否合算。对于外行来说，可能觉得程序好写了。问题是你
: 们不看文档么？OS早就支持直接通过线性地址访问硬盘的，有个东西叫mmap啊亲。
: CPU通过地址线直读硬盘的最大问题是，硬盘数据会占用CPU内部的cache，这是最快而
: 且最宝贵的资源。而硬盘就算是SSD也是远慢于内存的，不在中间插入一层相对低速但
: 是更大容量的cache，就是巨大的性能浪费。所以现在CPU别说硬盘，就连ROM都不直接
: 去读。
|
t*****s
发帖数: 416 | 29 您就别抱着您跟老师十年前学的那点破玩儿当真理了。
前沿的东西都只有看代码看论文，书出来都已经过时了不知道么。
装13还装得挺像叫人回去补课。
您去看看OpenCL的实现机制再来装13吧。
【在 x****u 的大作中提到】
: 你回炉补补课吧。
: 还GPU进程调度，老师没告诉你实现这个东西需要什么硬件代价么？
|
x****u
发帖数: 44466 | 30 有的算法需要随机访问外存大数据块时，用这个很方便。就算是open文件，后台还是要
做类似的事情。
【在 h****e 的大作中提到】
: 现在谁用mmap读硬盘啊，都是读网卡吧。
|
|
|
x****u
发帖数: 44466 | 31 觉得书过时，也是无知小孩的共性啊。。。
【在 t*****s 的大作中提到】
: 您就别抱着您跟老师十年前学的那点破玩儿当真理了。
: 前沿的东西都只有看代码看论文，书出来都已经过时了不知道么。
: 装13还装得挺像叫人回去补课。
: 您去看看OpenCL的实现机制再来装13吧。
|
t*****s
发帖数: 416 | 32 哎，你还真是被某人传染了。
以为你把不读书的tag说一千遍就真贴到我身上来了？
这年头低速设备加个小cache配个高速总线端口根本不是个事儿。
自己抱着N年前的过期知识不肯放还有脸叫别人学习。
麻烦你随便找个搞SOC的人问问现在总线构架的趋势是啥OK？
【在 x****u 的大作中提到】
: 你这小同学真是只会骂人但死也不读书啊。
: 自己设计一个类似系统，就知道为什么高速设备和低速是分开连的了。现在主板上几乎
: 所有功能都集中到一两个芯片里了，但这不是你放弃学习的理由。
|
x****u
发帖数: 44466 | 33 唉，能google到低速设备配小cache连高速总线，就没人告诉你有个系统调用叫mmap么？
【在 t*****s 的大作中提到】
: 哎，你还真是被某人传染了。
: 以为你把不读书的tag说一千遍就真贴到我身上来了？
: 这年头低速设备加个小cache配个高速总线端口根本不是个事儿。
: 自己抱着N年前的过期知识不肯放还有脸叫别人学习。
: 麻烦你随便找个搞SOC的人问问现在总线构架的趋势是啥OK？
|
t*****s
发帖数: 416 | 34 呵呵，倒是不敢提你的“CPU比内核快了么”
以为“内核态VS用户态”你胡搅蛮缠一下就能搅晕了？
“内核态无法有效利用系统服务”这真是搞笑啊。不说别的就说软件里的common sense
就知道强耦合的效率是高于模块化跟API之后的弱耦合的。内核态调用内核态的过程不
如用户态调用的效率高？拜托你胡扯也扯点稍微靠谱一点的行不？
更不要说用户态调用系统服务的时候首先要切换context，调完了还要恢复，能得出用
户态利用系统服务比内核态高这个结论，你也算是蠢到一定地步了。
你对系统的了解也就N年前老师告诉你的那些过时玩意儿了，自己手上碰都没碰过真家
伙，老师说的对不对也就全盘收了，难怪张口不离老师。
【在 x****u 的大作中提到】
: 这算学过CS么？你们OS老师告诉你内核态和用户态只差在内存访问权限上？
: 内核态最大问题是无法有效的利用系统服务，你自己写个小东西就知道，大多数算法放
: 入内核肯定要牺牲系统效率。
: 当年物理这一行热门的时候，是不是不学微积分的也敢证明相对论错误？
:
: 么。
|
t*****s
发帖数: 416 | 35 敢把这个当槽点正好说明你有多无知。
去读读Linux代码吧，别整天抱着你那过时的教科书和笔记了。
【在 x****u 的大作中提到】
: 又发现一个槽点：
: 内核态和用户态都在同一个CPU上跑，同学你真该补课了。。。
:
: 么。
|
L***n
发帖数: 6727 | 36 外行问一个，难道不是在一个cpu上跑?
【在 x****u 的大作中提到】
: 又发现一个槽点：
: 内核态和用户态都在同一个CPU上跑，同学你真该补课了。。。
:
: 么。
|
x****u
发帖数: 44466 | 37 你语文老师也要哭了。翻翻我评王先生的贴吧，你还真以为我在赞扬他？
恩，又来了，用户态调用系统服务要switch context。嫌书过时我也不强迫你看，拜托
你wikipedia一下什么叫switch context好么？
sense
【在 t*****s 的大作中提到】
: 呵呵，倒是不敢提你的“CPU比内核快了么”
: 以为“内核态VS用户态”你胡搅蛮缠一下就能搅晕了？
: “内核态无法有效利用系统服务”这真是搞笑啊。不说别的就说软件里的common sense
: 就知道强耦合的效率是高于模块化跟API之后的弱耦合的。内核态调用内核态的过程不
: 如用户态调用的效率高？拜托你胡扯也扯点稍微靠谱一点的行不？
: 更不要说用户态调用系统服务的时候首先要切换context，调完了还要恢复，能得出用
: 户态利用系统服务比内核态高这个结论，你也算是蠢到一定地步了。
: 你对系统的了解也就N年前老师告诉你的那些过时玩意儿了，自己手上碰都没碰过真家
: 伙，老师说的对不对也就全盘收了，难怪张口不离老师。
|
x****u
发帖数: 44466 | 38 敢问你连SMP也没听说过？
【在 t*****s 的大作中提到】
: 敢把这个当槽点正好说明你有多无知。
: 去读读Linux代码吧，别整天抱着你那过时的教科书和笔记了。
|
x****u
发帖数: 44466 | 39 用户态程序在Context Switch后会根据任务调度策略选择一个最合适的地方跑，内核态
的话需要结合OS具体讲，说来话长。
【在 L***n 的大作中提到】
: 外行问一个，难道不是在一个cpu上跑?
|
t*****s
发帖数: 416 | 40 就是您那些N年前的“定性”认识导致了你看系统既肤浅又可笑啊。
不同硬件的速度在随着时间飞速变化，速度之间的差距也在或缩小或拉大。像你这样拿
着30年前硬件速度“定性”地看问题……知道什么叫“刻舟求剑”么？
看来你知道个mmap就觉得自己是系统专家了啊。你知道mmap有多少overhead么？mmap本
来就是一个为传输速度跟不上的外设提供的折衷方案，也只有你这样的外行会觉得这个
是系统的根本性设计。至于SSD，显然在你眼里硬件只有速度一个指标，什么响应时间
、传输率都是速度嘛，也难怪你搞不清情况敢胡说八道。
【在 x****u 的大作中提到】
: 你这家伙真是对体系结构连个定性的认识都没有。
: 硬盘内存混合编址然后对CPU透明，技术上是毫无难度的，前面已经给你讲过了，硬盘
: 现在也是靠一个绝对地址读512xN字节块的。
: 问题是这么做是否有意义，是否合算。对于外行来说，可能觉得程序好写了。问题是你
: 们不看文档么？OS早就支持直接通过线性地址访问硬盘的，有个东西叫mmap啊亲。
: CPU通过地址线直读硬盘的最大问题是，硬盘数据会占用CPU内部的cache，这是最快而
: 且最宝贵的资源。而硬盘就算是SSD也是远慢于内存的，不在中间插入一层相对低速但
: 是更大容量的cache，就是巨大的性能浪费。所以现在CPU别说硬盘，就连ROM都不直接
: 去读。
|
|
|
t*****s
发帖数: 416 | 41 哟，又创造了一个新tag叫“Google到”
难道是你发现老师讲的东西好像不太make sense了赶紧去问google然后灵感一发觉得这
个tag肯定好用赶紧贴过来？
怎么不提你的高速总线低速总线了？
整天搞高层抽象的软件设计不了解底层不怪你，自以为是还要来跟系统工程师客场作战
就是你自己找抽了。
你还真以为知道个系统调用的名字就能震住人了？可笑。
么？
【在 x****u 的大作中提到】
: 唉，能google到低速设备配小cache连高速总线，就没人告诉你有个系统调用叫mmap么？
|
t*****s
发帖数: 416 | 42 我不用wikipedia就知道你又在秀无知了。
你以为用户态进入到内核态就是CPU一个模式bit的变化吧？老师这么教的嘛。
还是这个话，去看看Linux代码吧。您的老师水平很让人怀疑呢。
【在 x****u 的大作中提到】
: 你语文老师也要哭了。翻翻我评王先生的贴吧，你还真以为我在赞扬他？
: 恩，又来了，用户态调用系统服务要switch context。嫌书过时我也不强迫你看，拜托
: 你wikipedia一下什么叫switch context好么？
:
: sense
|
x****u
发帖数: 44466 | 43 数电模电微机原理统统逃课了么？
你这个想法放到过去的电脑上还真没问题。现在的电脑为了提高效率，对速度不同的设
备的连接方式极为在意，别说是硬盘或者SSD，连ROM都舍不得让CPU直接去碰。。。
你对系统编程有好感的原因，说是距离产生美也不为过。
【在 t*****s 的大作中提到】
: 就是您那些N年前的“定性”认识导致了你看系统既肤浅又可笑啊。
: 不同硬件的速度在随着时间飞速变化，速度之间的差距也在或缩小或拉大。像你这样拿
: 着30年前硬件速度“定性”地看问题……知道什么叫“刻舟求剑”么？
: 看来你知道个mmap就觉得自己是系统专家了啊。你知道mmap有多少overhead么？mmap本
: 来就是一个为传输速度跟不上的外设提供的折衷方案，也只有你这样的外行会觉得这个
: 是系统的根本性设计。至于SSD，显然在你眼里硬件只有速度一个指标，什么响应时间
: 、传输率都是速度嘛，也难怪你搞不清情况敢胡说八道。
|
t*****s
发帖数: 416 | 44 当然是，你看他还敢接茬么。
【在 L***n 的大作中提到】
: 外行问一个，难道不是在一个cpu上跑?
|
t*****s
发帖数: 416 | 45 你才要叫你语文老师哭。居然能读出我觉得你在赞王垠的意思来。
【在 x****u 的大作中提到】
: 你语文老师也要哭了。翻翻我评王先生的贴吧，你还真以为我在赞扬他？
: 恩，又来了，用户态调用系统服务要switch context。嫌书过时我也不强迫你看，拜托
: 你wikipedia一下什么叫switch context好么？
:
: sense
|
x****u
发帖数: 44466 | 46 小同学，高速低速设备怎么连接，基于什么思想的课本上都有，你嫌书过时不看书我才
建议你google一下。
mmap也能和吓唬人联系起来？下次我背九九表好了。。。
【在 t*****s 的大作中提到】
: 哟，又创造了一个新tag叫“Google到”
: 难道是你发现老师讲的东西好像不太make sense了赶紧去问google然后灵感一发觉得这
: 个tag肯定好用赶紧贴过来？
: 怎么不提你的高速总线低速总线了？
: 整天搞高层抽象的软件设计不了解底层不怪你，自以为是还要来跟系统工程师客场作战
: 就是你自己找抽了。
: 你还真以为知道个系统调用的名字就能震住人了？可笑。
:
: 么？
|
t*****s
发帖数: 416 | 47 you just made my day。
这个实在槽点太多，容我笑一会儿再来吐
【在 x****u 的大作中提到】
: 敢问你连SMP也没听说过？
|
x****u
发帖数: 44466 | 48 自己看看定义，然后上来承认一声错了不丢人。
http://en.wikipedia.org/wiki/Context_switch
User and kernel mode switching
When a transition between user mode and kernel mode is required in an
operating system, a context switch is not necessary; a mode transition is
not by itself a context switch. However, depending on the operating system,
a context switch may also take place at this time.
拜托
【在 t*****s 的大作中提到】
: 我不用wikipedia就知道你又在秀无知了。
: 你以为用户态进入到内核态就是CPU一个模式bit的变化吧？老师这么教的嘛。
: 还是这个话，去看看Linux代码吧。您的老师水平很让人怀疑呢。
|
x****u
发帖数: 44466 | 49 慢走不送。
【在 t*****s 的大作中提到】
: you just made my day。
: 这个实在槽点太多，容我笑一会儿再来吐
|
t*****s
发帖数: 416 | 50
笑够了，咱来数数本日最佳槽点。
首先，小菊花同学的知识体系里，区分内核态和用户态的操作系统在单核时代显然是不
存在的——内核态和用户态不能在同一个CPU上跑嘛，只有一个核怎么能有两种状态呢
。所以啊，linux这种操作系统，编译到老的单核CPU上的时候一定是把代码给HACK了个
底朝天，全部应用程序都在内核态跑……噗，不好意思我又忍不住了。
然后呢，小菊花同学又觉得，用户态和内核态既然不能在同一个CPU上跑，所以用户程
序调系统服务的时候肯定不是相context switch那样把当前的寄存器的值都给保存到内
存里，然后在同一个CPU上trap到内核态里进行操作，而是直接创造一个新的内核线程
，丢到隔壁CPU上去运行。这样这个CPU上的寄存器都不受影响了，也不存在context
switch的问题了嘛。
那么问题来了，80%的系统调用都是同步调用，要block的。这段时间这个CPU干啥呢？
小菊花同学严肃的表示，根据他从书上和老师那里学到的知识——闲着，闲着等隔壁
CPU上的内核线程。
可是，可是，多核的优势不就是在于并行计算吗？这样用了两个核只有一个核在干活，
不是很浪费吗？【不，这样用户态利用系统调用的效率就会比内核态高。】
噗
【在 x****u 的大作中提到】
: 又发现一个槽点：
: 内核态和用户态都在同一个CPU上跑，同学你真该补课了。。。
:
: 么。
|
|
|
t*****s
发帖数: 416 | 51 现在又开始聊思想了？
不提你的高低速多级总线了？不嘲笑我的总线构架扁平化了？
欢迎你背九九表啊。
【在 x****u 的大作中提到】
: 小同学，高速低速设备怎么连接，基于什么思想的课本上都有，你嫌书过时不看书我才
: 建议你google一下。
: mmap也能和吓唬人联系起来？下次我背九九表好了。。。
|
x****u
发帖数: 44466 | 52 何弃疗
【在 t*****s 的大作中提到】
: 现在又开始聊思想了？
: 不提你的高低速多级总线了？不嘲笑我的总线构架扁平化了？
: 欢迎你背九九表啊。
|
t*****s
发帖数: 416 | 53 “无知小孩”
又是一个新tag。
反正给人贴tag不要钱嘛。
先贴上展现一下气势，至于支持这个tag的论据嘛……先贴上再说，以后再慢慢找。找
不到就算了。万一以后我嘴上跑了火车给你供了点支持这个tag的弹药呢？对吧？
【在 x****u 的大作中提到】
: 觉得书过时，也是无知小孩的共性啊。。。
|
x****u
发帖数: 44466 | 54 本版很多网友和zhao同学或者是我都有很多意见不一致的地方，但你的表现实在是太让
他们失望了。人家甚至不好意思中间插嘴帮你说话。
【在 t*****s 的大作中提到】
: “无知小孩”
: 又是一个新tag。
: 反正给人贴tag不要钱嘛。
: 先贴上展现一下气势，至于支持这个tag的论据嘛……先贴上再说，以后再慢慢找。找
: 不到就算了。万一以后我嘴上跑了火车给你供了点支持这个tag的弹药呢？对吧？
|
t*****s
发帖数: 416 | 55 不不不，我怎么能放弃治疗呢，我的人生还很漫长，我还有那么多梦想没有实现。
求求您了，小菊花大神，救救我吧，不要放弃我。一定要把我这个相信“内核态和用户
态在同一个CPU上运行”的病给治好。
【在 x****u 的大作中提到】
: 何弃疗
|
t*****s
发帖数: 416 | 56 您这是战略转移开始走外围路线么？
跟您全技术领域专家的形象不符啊。
而且结论下这么早，一会儿万一有哥们儿吃完晚饭了来帮句腔，您可得怎么下台啊？
【在 x****u 的大作中提到】
: 本版很多网友和zhao同学或者是我都有很多意见不一致的地方，但你的表现实在是太让
: 他们失望了。人家甚至不好意思中间插嘴帮你说话。
|
x****u
发帖数: 44466 | 57 你还是混家版吧。
太让
【在 t*****s 的大作中提到】
: 您这是战略转移开始走外围路线么？
: 跟您全技术领域专家的形象不符啊。
: 而且结论下这么早，一会儿万一有哥们儿吃完晚饭了来帮句腔，您可得怎么下台啊？
|
t*****s
发帖数: 416 | 58 拜托您不清楚的就别说，不要误导人了好不好。
放你自己的贴里瞎说也就算了，放我的贴里我不纠正还得负连带责任。
所谓context switch就是在同一颗CPU上发生的事情。switch上去的用户进程和switch
下来的用户进程当然是在同一个CPU上跑的。只不过被switch下来的进程一会儿可能又
会被其他CPU switch上去。
从整体系统上看，每个CPU上都有一个scheduler，但是他们调度的范围都是整个系统的
所有进程。你这种“Context Switch后会根据任务调度策略选择一个最合适的地方跑“
的说法根本就是概念不清把两次context switch混成一次说的结果。
至于内核态根本没有什么所谓的说来话长，一个用户态进程call一个系统调用，系统调
用一定是在同一个CPU上直接执行。除非系统调用本身有异步操作，那样的话系统调用
发出异步请求之后会call scheduler，然后suspend保存到内存里去，一会儿被哪个CPU
上的scheduler叫醒才会不一定。
【在 x****u 的大作中提到】
: 用户态程序在Context Switch后会根据任务调度策略选择一个最合适的地方跑，内核态
: 的话需要结合OS具体讲，说来话长。
|
x****u
发帖数: 44466 | 59 “每个CPU上都有一个scheduler”
“至于内核态根本没有什么所谓的说来话长，一个用户态进程call一个系统调用，系统
调用一定是在同一个CPU上直接执行。除非系统调用本身有异步操作，那样的话系统调
用会call scheduler，然后suspend保存到内存里去，一会儿被哪个CPU上的scheduler
叫醒才会不一定。”
建议楼主改行，计算机和人民群众的生产生活安全关系太紧密了。。。
switch
核态
【在 t*****s 的大作中提到】
: 拜托您不清楚的就别说，不要误导人了好不好。
: 放你自己的贴里瞎说也就算了，放我的贴里我不纠正还得负连带责任。
: 所谓context switch就是在同一颗CPU上发生的事情。switch上去的用户进程和switch
: 下来的用户进程当然是在同一个CPU上跑的。只不过被switch下来的进程一会儿可能又
: 会被其他CPU switch上去。
: 从整体系统上看，每个CPU上都有一个scheduler，但是他们调度的范围都是整个系统的
: 所有进程。你这种“Context Switch后会根据任务调度策略选择一个最合适的地方跑“
: 的说法根本就是概念不清把两次context switch混成一次说的结果。
: 至于内核态根本没有什么所谓的说来话长，一个用户态进程call一个系统调用，系统调
: 用一定是在同一个CPU上直接执行。除非系统调用本身有异步操作，那样的话系统调用
|
t*****s
发帖数: 416 | 60 你今天秀的无知已经够多了。
好歹去稍微看看Linux代码再来争论吧。
这两句话涉及的Linux代码我都不知道看过多少遍了。就算你气势装得再足也不可能唬
过去的。
【在 x****u 的大作中提到】
: “每个CPU上都有一个scheduler”
: “至于内核态根本没有什么所谓的说来话长，一个用户态进程call一个系统调用，系统
: 调用一定是在同一个CPU上直接执行。除非系统调用本身有异步操作，那样的话系统调
: 用会call scheduler，然后suspend保存到内存里去，一会儿被哪个CPU上的scheduler
: 叫醒才会不一定。”
: 建议楼主改行，计算机和人民群众的生产生活安全关系太紧密了。。。
:
: switch
: 核态
|
|
|
x****u
发帖数: 44466 | 61 黑完了系统又要黑Linux了。。。
系统
scheduler
【在 t*****s 的大作中提到】
: 你今天秀的无知已经够多了。
: 好歹去稍微看看Linux代码再来争论吧。
: 这两句话涉及的Linux代码我都不知道看过多少遍了。就算你气势装得再足也不可能唬
: 过去的。
|
t*****s
发帖数: 416 | 62 你可以用大无畏的精神保持你的无知。但是请不要误导新人。
CPU在系统里是最高主宰，不存在一个更高的部件来替CPU决定该怎么scheduling。而
SMP结构的基本原则就是对称，所有CPU的地位相同。因此也不可能让一个CPU主宰其他
CPU的scheduling。所以唯一的解决方法就是每个CPU都自己为自己scheduling，但是大
家共用一个进程表，从同一个进程表里拿进程，换下来的进程放到同一个进程表里去。
Linux上就是这么做的。Unix也是。而且这个属于经典设计。
这个帖子本来我一开始就说了不想吵架的。结果你还是非冲进来要吵。现在在这种明确
无误的问题上站在错误的观点上被逼到死角。
说实话，我觉得你很可悲。
【在 x****u 的大作中提到】
: 黑完了系统又要黑Linux了。。。
:
: 系统
: scheduler
|
x****u
发帖数: 44466 | 63 赞楼主不是新人。
关于槽点1：
“每个CPU上都有一个scheduler”
楼主不如说每个CPU上都运行着一个linux，你们老师没告诉过你OS是公用服务么？调度
的代码放在全体CPU共用的内存上，和其他代码一样一共只有一份，只有在需要时才会
被执行。
关于槽点2：
“至于内核态根本没有什么所谓的说来话长，一个用户态进程call一个系统调用，系统
调用一定是在同一个CPU上直接执行。除非系统调用本身有异步操作，那样的话系统调
用会call scheduler，然后suspend保存到内存里去，一会儿被哪个CPU上的scheduler
叫醒才会不一定。”
本来书里也有但是你觉得过时，那就google“Kernel Preemption”吧。
去。
【在 t*****s 的大作中提到】
: 你可以用大无畏的精神保持你的无知。但是请不要误导新人。
: CPU在系统里是最高主宰，不存在一个更高的部件来替CPU决定该怎么scheduling。而
: SMP结构的基本原则就是对称，所有CPU的地位相同。因此也不可能让一个CPU主宰其他
: CPU的scheduling。所以唯一的解决方法就是每个CPU都自己为自己scheduling，但是大
: 家共用一个进程表，从同一个进程表里拿进程，换下来的进程放到同一个进程表里去。
: Linux上就是这么做的。Unix也是。而且这个属于经典设计。
: 这个帖子本来我一开始就说了不想吵架的。结果你还是非冲进来要吵。现在在这种明确
: 无误的问题上站在错误的观点上被逼到死角。
: 说实话，我觉得你很可悲。
|
t****t
发帖数: 6806 | 64 他说的这些, 除了没有提到同一个线程在执行过的CPU上会稍微优先以外, 别的看上去都
跟我知道的差不多.
你觉得有什么问题的话不如纠正一下, 我也学习学习.
scheduler
【在 x****u 的大作中提到】
: “每个CPU上都有一个scheduler”
: “至于内核态根本没有什么所谓的说来话长，一个用户态进程call一个系统调用，系统
: 调用一定是在同一个CPU上直接执行。除非系统调用本身有异步操作，那样的话系统调
: 用会call scheduler，然后suspend保存到内存里去，一会儿被哪个CPU上的scheduler
: 叫醒才会不一定。”
: 建议楼主改行，计算机和人民群众的生产生活安全关系太紧密了。。。
:
: switch
: 核态
|
t****t
发帖数: 6806 | 65 第一点原来你说的是代码共享, 这个不需要特别指出吧. 他也没说运行不同的schedule
r不是.
scheduler
【在 x****u 的大作中提到】
: 赞楼主不是新人。
: 关于槽点1：
: “每个CPU上都有一个scheduler”
: 楼主不如说每个CPU上都运行着一个linux，你们老师没告诉过你OS是公用服务么？调度
: 的代码放在全体CPU共用的内存上，和其他代码一样一共只有一份，只有在需要时才会
: 被执行。
: 关于槽点2：
: “至于内核态根本没有什么所谓的说来话长，一个用户态进程call一个系统调用，系统
: 调用一定是在同一个CPU上直接执行。除非系统调用本身有异步操作，那样的话系统调
: 用会call scheduler，然后suspend保存到内存里去，一会儿被哪个CPU上的scheduler
|
t*****s
发帖数: 416 | 66 唉。
我都不忍心了。
不愧是玩弄文字的大师，这么快就想到用代码来狡辩
OS的代码内存自然只有一份。
但是所有的CPU有可能同时运行scheduler的代码，而且这些scheduler的运行实例之间
除了不能同时操作进程表以外互不干涉。
假设你在用户态运行了10个进程的browser，你要因为他们共享程序代码就说成你只开
了1个browser么？
如果你要说这就是你的本意，那也随你。我并不像你以踩人为乐。概念给其他看帖的人
说清楚就好。
至于kernel preemption，并不改变我说的关于系统调用过程的正确性。只不过存在
kernel preemption的情况下，我上面说的任何一步都可以被打断而suspend。但是从进
程本身的视角来说，整个过程并没有改变。
何况kernel preemption对处于用户态和内核态的进程都同样有影响。要考虑它也不存
在“内核态说来话长的问题”。你也应该收起以为丢一个你自以为新颖少见的名词就能
让人被震住的态度了。
：关于槽点1：
：“每个CPU上都有一个scheduler”
：楼主不如说每个CPU上都运行着一个linux，你们老师没告诉过你OS是公用服务么？调度
：的代码放在全体CPU共用的内存上，和其他代码一样一共只有一份，只有在需要时才会
：被执行。
关于槽点2：
：“至于内核态根本没有什么所谓的说来话长，一个用户态进程call一个系统调用，系统
：调用一定是在同一个CPU上直接执行。除非系统调用本身有异步操作，那样的话系统调
：用会call scheduler，然后suspend保存到内存里去，一会儿被哪个CPU上的
scheduler
：叫醒才会不一定。”
：本来书里也有但是你觉得过时，那就google“Kernel Preemption”吧。
：
：【 在 tcelvis (光头) 的大作中提到: 】
：: 你可以用大无畏的精神保持你的无知。但是请不要误导新人。
：: CPU在系统里是最高主宰，不存在一个更高的部件来替CPU决定该怎么scheduling。而
其他
是大
：：去。
明确
【在 x****u 的大作中提到】
: 赞楼主不是新人。
: 关于槽点1：
: “每个CPU上都有一个scheduler”
: 楼主不如说每个CPU上都运行着一个linux，你们老师没告诉过你OS是公用服务么？调度
: 的代码放在全体CPU共用的内存上，和其他代码一样一共只有一份，只有在需要时才会
: 被执行。
: 关于槽点2：
: “至于内核态根本没有什么所谓的说来话长，一个用户态进程call一个系统调用，系统
: 调用一定是在同一个CPU上直接执行。除非系统调用本身有异步操作，那样的话系统调
: 用会call scheduler，然后suspend保存到内存里去，一会儿被哪个CPU上的scheduler
|
x****u
发帖数: 44466 | 67 scheduler和别的代码一样，谈不上每个CPU上有一份之类的。
进程也可能被在每个CPU上执行，能说每个CPU上都有一个进程么？
schedule
【在 t****t 的大作中提到】
: 第一点原来你说的是代码共享, 这个不需要特别指出吧. 他也没说运行不同的schedule
: r不是.
:
: scheduler
|
t****t
发帖数: 6806 | 68 如果进程同时在两个CPU上执行, 那我就说两个CPU上都有一个进程, 一共两个进程, 这
没什么问题啊. 现在代码缺省就是一份. 看几个进程是看几份数据. scheduler在每个C
PU上都执行, 每个CPU有基本独立的scheduler data, 说每个CPU一个scheduler没问题.
【在 x****u 的大作中提到】
: scheduler和别的代码一样，谈不上每个CPU上有一份之类的。
: 进程也可能被在每个CPU上执行，能说每个CPU上都有一个进程么？
:
: schedule
|
x****u
发帖数: 44466 | 69 问题大了啊！
启动两个进程和同一个进程在被调度到两个CPU上执行，是不同的概念。就算咱们用进
程的概念来说，两个CPU运行的scheduler算是不同进程么？有不同的TSS么？
个C
题.
【在 t****t 的大作中提到】
: 如果进程同时在两个CPU上执行, 那我就说两个CPU上都有一个进程, 一共两个进程, 这
: 没什么问题啊. 现在代码缺省就是一份. 看几个进程是看几份数据. scheduler在每个C
: PU上都执行, 每个CPU有基本独立的scheduler data, 说每个CPU一个scheduler没问题.
|
t*****s
发帖数: 416 | 70 所以你也同意“一个”进程不能同时在多个CPU上运行对么。
scheduler可以，所以是多个。
就这么简单。
【在 x****u 的大作中提到】
: 问题大了啊！
: 启动两个进程和同一个进程在被调度到两个CPU上执行，是不同的概念。就算咱们用进
: 程的概念来说，两个CPU运行的scheduler算是不同进程么？有不同的TSS么？
:
: 个C
: 题.
|
|
|
t*****s
发帖数: 416 | 71 这里是广义进程，把线程当作弱进程考虑。免得你每次没词了就想把问题复杂化。
你也不要想抓这个问题。线程从调度的视角来说和正常进程是完全一样的。
【在 t*****s 的大作中提到】
: 所以你也同意“一个”进程不能同时在多个CPU上运行对么。
: scheduler可以，所以是多个。
: 就这么简单。
|
x****u
发帖数: 44466 | 72 这年头“kernel preemption”都算新颖少见的名词了，你真是不给粉丝团面子。
你再使劲读读代码，先弄清“被打断”的意思吧。
“
至于kernel preemption，并不改变我说的关于系统调用过程的正确性。只不过存在
kernel preemption的情况下，我上面说的任何一步都可以被打断而suspend。但是从进
程本身的视角来说，整个过程并没有改变。
何况kernel preemption对处于用户态和内核态的进程都同样有影响。要考虑它也不存
在“内核态说来话长的问题”。你也应该收起以为丢一个你自以为新颖少见的名词就能
让人被震住的态度了。
”
【在 t*****s 的大作中提到】
: 唉。
: 我都不忍心了。
: 不愧是玩弄文字的大师，这么快就想到用代码来狡辩
: OS的代码内存自然只有一份。
: 但是所有的CPU有可能同时运行scheduler的代码，而且这些scheduler的运行实例之间
: 除了不能同时操作进程表以外互不干涉。
: 假设你在用户态运行了10个进程的browser，你要因为他们共享程序代码就说成你只开
: 了1个browser么？
: 如果你要说这就是你的本意，那也随你。我并不像你以踩人为乐。概念给其他看帖的人
: 说清楚就好。
|
t****t
发帖数: 6806 | 73 我本来没把进程和scheduler相比, 是你自己要类比的啊.
你要拿TSS来说的话, scheduler本身不能算进程(线程)吧.
【在 x****u 的大作中提到】
: 问题大了啊！
: 启动两个进程和同一个进程在被调度到两个CPU上执行，是不同的概念。就算咱们用进
: 程的概念来说，两个CPU运行的scheduler算是不同进程么？有不同的TSS么？
:
: 个C
: 题.
|
x****u
发帖数: 44466 | 74 您老原话在这里：
“
如果进程同时在两个CPU上执行, 那我就说两个CPU上都有一个进程, 一共两个进程, 这
没什么问题啊. 现在代码缺省就是一份. 看几个进程是看几份数据. scheduler在每个C
PU上都执行, 每个CPU有基本独立的scheduler data, 说每个CPU一个scheduler没问题.
”
用进
【在 t****t 的大作中提到】
: 我本来没把进程和scheduler相比, 是你自己要类比的啊.
: 你要拿TSS来说的话, scheduler本身不能算进程(线程)吧.
|
x****u
发帖数: 44466 | 75 楼主把scheduler当线程看？OMG，赶紧回去翻书，还有个更恰当的名字叫什么来着？
【在 t*****s 的大作中提到】
: 这里是广义进程，把线程当作弱进程考虑。免得你每次没词了就想把问题复杂化。
: 你也不要想抓这个问题。线程从调度的视角来说和正常进程是完全一样的。
|
t*****s
发帖数: 416 | 76 你无非就是每次发现自己说错了以后引入一个新的因素来把问题复杂化。
好吧，那我们就按复杂的来。
说kernel preemption。
如果发生在当前进程处于用户态时。
那么不存在你所谓的“内核态说来话长“的问题。
如果发生在当前进程处于用户态时。
那么我说的“一个用户态进程call一个系统调用，系统调用一定是在同一个CPU上直接
执行。”这个过程已经完成了。也不存在问题。
只不过除了“除非系统调用本身有异步操作，那样的话系统调用会call scheduler，然
后suspend保存到内存里去，一会儿被哪个CPU上的scheduler叫起来才会不一定“这个
我说了的特例以外，还有一种特例是系统调用执行到一半被irq handler等高级别代码
preemption，于是suspend到内存里去。
有什么错？
【在 x****u 的大作中提到】
: 这年头“kernel preemption”都算新颖少见的名词了，你真是不给粉丝团面子。
: 你再使劲读读代码，先弄清“被打断”的意思吧。
: “
: 至于kernel preemption，并不改变我说的关于系统调用过程的正确性。只不过存在
: kernel preemption的情况下，我上面说的任何一步都可以被打断而suspend。但是从进
: 程本身的视角来说，整个过程并没有改变。
: 何况kernel preemption对处于用户态和内核态的进程都同样有影响。要考虑它也不存
: 在“内核态说来话长的问题”。你也应该收起以为丢一个你自以为新颖少见的名词就能
: 让人被震住的态度了。
: ”
|
t*****s
发帖数: 416 | 77 自己打自己嘴巴。
【在 x****u 的大作中提到】
: 楼主把scheduler当线程看？OMG，赶紧回去翻书，还有个更恰当的名字叫什么来着？
|
x****u
发帖数: 44466 | 78 你的贴真是不能细读啊：
“
还有一种特例是系统调用执行到一半被irq handler等高级别代码
preemption，于是suspend到内存里去。
”
【在 t*****s 的大作中提到】
: 你无非就是每次发现自己说错了以后引入一个新的因素来把问题复杂化。
: 好吧，那我们就按复杂的来。
: 说kernel preemption。
: 如果发生在当前进程处于用户态时。
: 那么不存在你所谓的“内核态说来话长“的问题。
: 如果发生在当前进程处于用户态时。
: 那么我说的“一个用户态进程call一个系统调用，系统调用一定是在同一个CPU上直接
: 执行。”这个过程已经完成了。也不存在问题。
: 只不过除了“除非系统调用本身有异步操作，那样的话系统调用会call scheduler，然
: 后suspend保存到内存里去，一会儿被哪个CPU上的scheduler叫起来才会不一定“这个
|
x****u
发帖数: 44466 | 79 楼主逻辑常人跟不上了。
用进
【在 t*****s 的大作中提到】
: 自己打自己嘴巴。
|
x****u
发帖数: 44466 | 80 “一个用户态进程call一个系统调用，系统调用一定是在同一个CPU上直接执行。”
你让thrust给你讲讲，内核被抢占后可能发生什么事情吧。
【在 t*****s 的大作中提到】
: 你无非就是每次发现自己说错了以后引入一个新的因素来把问题复杂化。
: 好吧，那我们就按复杂的来。
: 说kernel preemption。
: 如果发生在当前进程处于用户态时。
: 那么不存在你所谓的“内核态说来话长“的问题。
: 如果发生在当前进程处于用户态时。
: 那么我说的“一个用户态进程call一个系统调用，系统调用一定是在同一个CPU上直接
: 执行。”这个过程已经完成了。也不存在问题。
: 只不过除了“除非系统调用本身有异步操作，那样的话系统调用会call scheduler，然
: 后suspend保存到内存里去，一会儿被哪个CPU上的scheduler叫起来才会不一定“这个
|
|
|
t****t
发帖数: 6806 | 81 你把我说过的话重复一遍是什么意思?
你说拿进程来比较scheduler, 本来scheduler不是进程, 但是你要比较也可以, 那我们
就看有几份data来区分"一份"还是"几份". 如果进程*同时*在两个CPU上都执行, 说明有
两份data, 就是两个进程. 如果你觉得我说得不对, 欢迎指出. 这个和前途问题不一样
, 有明确对错, 我愿意奉陪一下.
个C
题.
【在 x****u 的大作中提到】
: 您老原话在这里：
: “
: 如果进程同时在两个CPU上执行, 那我就说两个CPU上都有一个进程, 一共两个进程, 这
: 没什么问题啊. 现在代码缺省就是一份. 看几个进程是看几份数据. scheduler在每个C
: PU上都执行, 每个CPU有基本独立的scheduler data, 说每个CPU一个scheduler没问题.
: ”
:
: 用进
|
t*****s
发帖数: 416 | 82 你爱扣字眼就扣吧。
这个帖子本意是介绍系统的。
这个scheduler是怎么工作的，系统调用怎么执行已经说清楚了。
我也懒得和一个无赖争谁对谁错。
你本来怎么想的你自己心里清楚。
围观群众自己也会有判断。
我先睡觉去了。
【在 x****u 的大作中提到】
: 你的贴真是不能细读啊：
: “
: 还有一种特例是系统调用执行到一半被irq handler等高级别代码
: preemption，于是suspend到内存里去。
: ”
|
t****t
发帖数: 6806 | 83 要我讲的话我觉得他说得没错, preemption不管在用户态还是内核态都有可能发生, 但
是系统调用本身是在同一个CPU上没错啊. 这两个基本上是正交的概念, 你为啥要把它们
混起来.
【在 x****u 的大作中提到】
: “一个用户态进程call一个系统调用，系统调用一定是在同一个CPU上直接执行。”
: 你让thrust给你讲讲，内核被抢占后可能发生什么事情吧。
|
t*****s
发帖数: 416 | 84 他的伎俩就是自己说错了就把问题复杂化，最低也要弄成两个人都没说全对。
别跟它浪费时间了。
它们
【在 t****t 的大作中提到】
: 要我讲的话我觉得他说得没错, preemption不管在用户态还是内核态都有可能发生, 但
: 是系统调用本身是在同一个CPU上没错啊. 这两个基本上是正交的概念, 你为啥要把它们
: 混起来.
|
x****u
发帖数: 44466 | 85 加上“同时”二字后没大问题。
老大，scheduler用线程/进程类比是极不恰当的，我已经提醒那位同学回去查书了，他
一会就会修正自己的理论的。
明有
【在 t****t 的大作中提到】
: 你把我说过的话重复一遍是什么意思?
: 你说拿进程来比较scheduler, 本来scheduler不是进程, 但是你要比较也可以, 那我们
: 就看有几份data来区分"一份"还是"几份". 如果进程*同时*在两个CPU上都执行, 说明有
: 两份data, 就是两个进程. 如果你觉得我说得不对, 欢迎指出. 这个和前途问题不一样
: , 有明确对错, 我愿意奉陪一下.
:
: 个C
: 题.
|
x****u
发帖数: 44466 | 86 你的确该好好休息。
【在 t*****s 的大作中提到】
: 你爱扣字眼就扣吧。
: 这个帖子本意是介绍系统的。
: 这个scheduler是怎么工作的，系统调用怎么执行已经说清楚了。
: 我也懒得和一个无赖争谁对谁错。
: 你本来怎么想的你自己心里清楚。
: 围观群众自己也会有判断。
: 我先睡觉去了。
|
x****u
发帖数: 44466 | 87 被调度以后还能保证CPU不变么？
它们
【在 t****t 的大作中提到】
: 要我讲的话我觉得他说得没错, preemption不管在用户态还是内核态都有可能发生, 但
: 是系统调用本身是在同一个CPU上没错啊. 这两个基本上是正交的概念, 你为啥要把它们
: 混起来.
|
t****t
发帖数: 6806 | 88 这样说没必要, 你看我就只说事不说人, 如果说人我不奉陪就是了.
【在 t*****s 的大作中提到】
: 他的伎俩就是自己说错了就把问题复杂化，最低也要弄成两个人都没说全对。
: 别跟它浪费时间了。
:
: 它们
|
t****t
发帖数: 6806 | 89 那我也贴一下"原话", 你先类比的呀. "同时"我从一开始就说了, 你没看见是另一回事.
发信人: xiaoju (可爱的龙猫), 信区: Programming
标 题: Re: 关于OS级JVM
发信站: BBS 未名空间站 (Tue Oct 1 00:55:37 2013, 美东)
scheduler和别的代码一样，谈不上每个CPU上有一份之类的。
进程也可能被在每个CPU上执行，能说每个CPU上都有一个进程么？
【在 x****u 的大作中提到】
: 加上“同时”二字后没大问题。
: 老大，scheduler用线程/进程类比是极不恰当的，我已经提醒那位同学回去查书了，他
: 一会就会修正自己的理论的。
:
: 明有
|
t****t
发帖数: 6806 | 90 当然不能, 但这跟系统调用没关系不是么? 系统调用之前也会被调度.
【在 x****u 的大作中提到】
: 被调度以后还能保证CPU不变么？
:
: 它们
|
|
|
x****u
发帖数: 44466 | 91 从线性地址角度谈的把kernel space当成一个进程看没问题，但从多任务角度上说，调
度器和进程不相似。
事.
【在 t****t 的大作中提到】
: 那我也贴一下"原话", 你先类比的呀. "同时"我从一开始就说了, 你没看见是另一回事.
: 发信人: xiaoju (可爱的龙猫), 信区: Programming
: 标 题: Re: 关于OS级JVM
: 发信站: BBS 未名空间站 (Tue Oct 1 00:55:37 2013, 美东)
: scheduler和别的代码一样，谈不上每个CPU上有一份之类的。
: 进程也可能被在每个CPU上执行，能说每个CPU上都有一个进程么？
|
x****u
发帖数: 44466 | 92 这位小同学原话是这样的：
“一个用户态进程call一个系统调用，系统调用一定是在同一个CPU上直接执行。”
这应该是google到了Linux内核抢占流行前某人说的话。
BTW，所以我主张在看好了课本的前提下基于NT实践一下OS概念，至少NT的入门资料首
先就讲内核，调度的规定。
【在 t****t 的大作中提到】
: 当然不能, 但这跟系统调用没关系不是么? 系统调用之前也会被调度.
|
t****t
发帖数: 6806 | 93 有人说相似吗? 你自己先拿进程来类比scheduler的. 不管怎么说, 我觉得说每个CPU运
行一个scheduler没问题, 因为每个CPU有自己的scheduler数据, 也可能同时运行sched
uler.
【在 x****u 的大作中提到】
: 从线性地址角度谈的把kernel space当成一个进程看没问题，但从多任务角度上说，调
: 度器和进程不相似。
:
: 事.
|
x****u
发帖数: 44466 | 94 那么你可以说每个CPU上都运行一个OS么？SMP也可以并行执行OS代码。
sched
【在 t****t 的大作中提到】
: 有人说相似吗? 你自己先拿进程来类比scheduler的. 不管怎么说, 我觉得说每个CPU运
: 行一个scheduler没问题, 因为每个CPU有自己的scheduler数据, 也可能同时运行sched
: uler.
|
t****t
发帖数: 6806 | 95 我理解他说的意思, 并且觉得你抠字眼很没意义.
【在 x****u 的大作中提到】
: 这位小同学原话是这样的：
: “一个用户态进程call一个系统调用，系统调用一定是在同一个CPU上直接执行。”
: 这应该是google到了Linux内核抢占流行前某人说的话。
: BTW，所以我主张在看好了课本的前提下基于NT实践一下OS概念，至少NT的入门资料首
: 先就讲内核，调度的规定。
|
x****u
发帖数: 44466 | 96 拜托专业点好不好，这是驱动开发基本知识了。
如果在所有的内核代码里面都假定CPU不变，系统会当掉。内核里面如果不想被抢占，
Linux或者NT都有自己的做法，也要付出代价。
当年Linux内核改抢占时，也是闹得鸡飞狗跳的。。。
料首
【在 t****t 的大作中提到】
: 我理解他说的意思, 并且觉得你抠字眼很没意义.
|
t****t
发帖数: 6806 | 97 我继续觉得抠字眼没什么意思, 但是如果一定要抠的话, 还是那句话, 看data. 内核里
所有的data都是OS的, 所以没有多个copy. 如果你跑两个虚拟机, 就是两个OS了, 不过
它们share CPU, 所以OS和CPU没有一一对应的关系. 但是scheduler和CPU有.
【在 x****u 的大作中提到】
: 那么你可以说每个CPU上都运行一个OS么？SMP也可以并行执行OS代码。
:
: sched
|
t****t
发帖数: 6806 | 98 我不喜欢恶意揣测别人的想法. 如果有人话没有说全的话, 我缺省认为他只是懒得说而
已. 另一个option是认为他根本不懂只是google来的. 我选前者.
【在 x****u 的大作中提到】
: 拜托专业点好不好，这是驱动开发基本知识了。
: 如果在所有的内核代码里面都假定CPU不变，系统会当掉。内核里面如果不想被抢占，
: Linux或者NT都有自己的做法，也要付出代价。
: 当年Linux内核改抢占时，也是闹得鸡飞狗跳的。。。
:
: 料首
|
x****u
发帖数: 44466 | 99 Scheduler有多个copy？拜托顶多可以说scheduler维护了每个CPU的数据结构而已。
调度策略是基于全局的，不是单个CPU的独立行为。当然每个CPU的进程代码在时间片用
完后都会触发调度器，这只是调度的一小部分。
【在 t****t 的大作中提到】
: 我继续觉得抠字眼没什么意思, 但是如果一定要抠的话, 还是那句话, 看data. 内核里
: 所有的data都是OS的, 所以没有多个copy. 如果你跑两个虚拟机, 就是两个OS了, 不过
: 它们share CPU, 所以OS和CPU没有一一对应的关系. 但是scheduler和CPU有.
|
x****u
发帖数: 44466 | 100 没有人恶意揣测他的原话，但他自己说
“一个用户态进程call一个系统调用，系统调用一定是在同一个CPU上直接执行。”
是从Linux代码里面看到的，看了很多遍。
Linux实现“内核抢占”的历史都快10年了，我不得不理性怀疑一下他是否真的看过
Linux的代码或者书。
也许不是google来的而是百度来的，或者自己在网贴上看来的，这无所谓，只要不是从
Linux代码里看来的，就是一回事。
【在 t****t 的大作中提到】
: 我不喜欢恶意揣测别人的想法. 如果有人话没有说全的话, 我缺省认为他只是懒得说而
: 已. 另一个option是认为他根本不懂只是google来的. 我选前者.
|
|
|
t****t
发帖数: 6806 | 101 好, scheduler维护了每个CPU的数据结构. 这仍然是data不是吗? 队列, 优先级, 锁,
都在"每个CPU的数据结构"里了. 当然进程表是全局的.
【在 x****u 的大作中提到】
: Scheduler有多个copy？拜托顶多可以说scheduler维护了每个CPU的数据结构而已。
: 调度策略是基于全局的，不是单个CPU的独立行为。当然每个CPU的进程代码在时间片用
: 完后都会触发调度器，这只是调度的一小部分。
|
t****t
发帖数: 6806 | 102 我觉得他的意思是, 系统调用这个动作本身不引发CPU的切换, 或者说系统调用本身与s
cheduler没有直接关系. 你一定要理解成整个系统调用不切换CPU, 那也是你的自由.
【在 x****u 的大作中提到】
: 没有人恶意揣测他的原话，但他自己说
: “一个用户态进程call一个系统调用，系统调用一定是在同一个CPU上直接执行。”
: 是从Linux代码里面看到的，看了很多遍。
: Linux实现“内核抢占”的历史都快10年了，我不得不理性怀疑一下他是否真的看过
: Linux的代码或者书。
: 也许不是google来的而是百度来的，或者自己在网贴上看来的，这无所谓，只要不是从
: Linux代码里看来的，就是一回事。
|
x****u
发帖数: 44466 | 103 如果抬杠没意思了。调度器和普通task相比，CPU独立性更差你承认不？
,
【在 t****t 的大作中提到】
: 好, scheduler维护了每个CPU的数据结构. 这仍然是data不是吗? 队列, 优先级, 锁,
: 都在"每个CPU的数据结构"里了. 当然进程表是全局的.
|
t****t
发帖数: 6806 | 104 啥叫CPU独立性? 每个scheduler的数据是bound在一个CPU上的, 并且不切换, 你是这意
思吗?
【在 x****u 的大作中提到】
: 如果抬杠没意思了。调度器和普通task相比，CPU独立性更差你承认不？
:
: ,
|
x****u
发帖数: 44466 | 105 整个系统调用阶段不切换CPU也是存在过的，而且很有意义。早期内核里面代码质量不
高时，这么做可以避免一大堆的错误，但牺牲的是效率。
你完全可以认为即使别人说了什么错话，脑补后正确就行。这是你的自由。
与s
是从
【在 t****t 的大作中提到】
: 我觉得他的意思是, 系统调用这个动作本身不引发CPU的切换, 或者说系统调用本身与s
: cheduler没有直接关系. 你一定要理解成整个系统调用不切换CPU, 那也是你的自由.
|
x****u
发帖数: 44466 | 106 谈谈“数据”怎么“bound在一个CPU”上，并且不切换？
【在 t****t 的大作中提到】
: 啥叫CPU独立性? 每个scheduler的数据是bound在一个CPU上的, 并且不切换, 你是这意
: 思吗?
|
t****t
发帖数: 6806 | 107 就是这一堆数据是用来指导这个特定的CPU做scheduling的, 别的CPU不用它. --我觉得
从上下文来看, 我意思很清楚.
【在 x****u 的大作中提到】
: 谈谈“数据”怎么“bound在一个CPU”上，并且不切换？
|
t****t
发帖数: 6806 | 108 嗯, 总算达成了某种程度上的一致, 不容易啊.
【在 x****u 的大作中提到】
: 整个系统调用阶段不切换CPU也是存在过的，而且很有意义。早期内核里面代码质量不
: 高时，这么做可以避免一大堆的错误，但牺牲的是效率。
: 你完全可以认为即使别人说了什么错话，脑补后正确就行。这是你的自由。
:
: 与s
: 是从
|
x****u
发帖数: 44466 | 109 所以我说这种观点是不对的。
特定CPU在做scheduling时也要参考其他CPU的状态，比如A核在B核空闲时，一个等待任
务存在的时候，就不应该切换到新任务，而应该让B核去做。
【在 t****t 的大作中提到】
: 就是这一堆数据是用来指导这个特定的CPU做scheduling的, 别的CPU不用它. --我觉得
: 从上下文来看, 我意思很清楚.
|
t****t
发帖数: 6806 | 110 这个我已经说过了, 下次麻烦你脑补.
http://www.mitbbs.com/article1/Programming/31270491_3_0.html
【在 x****u 的大作中提到】
: 所以我说这种观点是不对的。
: 特定CPU在做scheduling时也要参考其他CPU的状态，比如A核在B核空闲时，一个等待任
: 务存在的时候，就不应该切换到新任务，而应该让B核去做。
|
|
|
x****u
发帖数: 44466 | 111 求指教，“这一堆数据”“别的CPU不用它”怎么补？
原帖在这里：
http://mitbbs.com/article1/Programming/31270593_3_0.html
待任
【在 t****t 的大作中提到】
: 就是这一堆数据是用来指导这个特定的CPU做scheduling的, 别的CPU不用它. --我觉得
: 从上下文来看, 我意思很清楚.
|
t****t
发帖数: 6806 | 112 我觉得跟你说话真累, 需要想了又想. 算了我玩游戏去了.
【在 x****u 的大作中提到】
: 求指教，“这一堆数据”“别的CPU不用它”怎么补？
: 原帖在这里：
: http://mitbbs.com/article1/Programming/31270593_3_0.html
:
: 待任
|
x****u
发帖数: 44466 | 113 不就是闲聊闲扯嘛，玩游戏也累脑子不是。
【在 t****t 的大作中提到】
: 我觉得跟你说话真累, 需要想了又想. 算了我玩游戏去了.
|
t*****s
发帖数: 416 | 114
“也许不是google来的而是百度来的，或者自己在网贴上看来的，这无所谓，只要不是
从Linux代码里看来的，就是一回事。”
“没有人恶意揣测他的原话”
呵呵，人无耻到你这个地步也算是一种境界。
要扣字眼，好咱们来扣字眼。
“一个用户态进程call一个系统调用，系统调用一定是在同一个CPU上直接执行。”
最后一个词，“执行”
这是一个动词。
前一个词，“直接”，immediately，表示动作是即时发生的。
很显然我是在描述call系统调用这个动作。不故意歪曲的话，有什么歧义？
结合后文，
“除非系统调用本身有异步操作，那样的话系统调用会call scheduler，然后suspend
保存到内存里去，一会儿被哪个CPU上的scheduler叫醒才会不一定。”
后面我在说系统调用执行过程中的内容。更显然前面这句话描述的是进入系统调用的这
个动作。
换个角度。
这句话直译成英文:
When a user process call a system call, the system call will surely be
executed on the same CPU immediately.
有什么错？
结果到了你嘴里，立刻变成了“系统调用一定会在同一个CPU上完成”。难怪你还得把
我后面半段截掉才敢一遍遍帖。因为我后面半段已经说了可能不会在同一个CPU上完成
，只不过一定是在同一个上开始了。
你还真不愧是玩弄文字的大师，利用中文语义模糊的特点，断章取义出来之后还反复的
重复你的扭曲解释。然后得出结论是我从网上看来的。
怎么，被打脸打疼了不用下三滥的手法不解恨了？
既然你这么不要脸了。咱们就揭揭你的伤疤。
http://www.mitbbs.com/article/Programming/31270443_0.html
这段话的根源是啥呢？
http://www.mitbbs.com/article/Programming/31270389_0.html
“内核态最大问题是无法有效的利用系统服务”
既然我说什么都是网上找来的，请您展开说说内核态怎么就无法有效利用系统服务了吧
。
【在 x****u 的大作中提到】
: 没有人恶意揣测他的原话，但他自己说
: “一个用户态进程call一个系统调用，系统调用一定是在同一个CPU上直接执行。”
: 是从Linux代码里面看到的，看了很多遍。
: Linux实现“内核抢占”的历史都快10年了，我不得不理性怀疑一下他是否真的看过
: Linux的代码或者书。
: 也许不是google来的而是百度来的，或者自己在网贴上看来的，这无所谓，只要不是从
: Linux代码里看来的，就是一回事。
|
x****u
发帖数: 44466 | 115 求你别侮辱我和thrust的智商了好不好！
对啊，显然你“是在描述call系统调用这个动作”，直接说任何x86的指令，都一定是
在“同一个CPU上直接执行”算了。
【在 t*****s 的大作中提到】
:
: “也许不是google来的而是百度来的，或者自己在网贴上看来的，这无所谓，只要不是
: 从Linux代码里看来的，就是一回事。”
: “没有人恶意揣测他的原话”
: 呵呵，人无耻到你这个地步也算是一种境界。
: 要扣字眼，好咱们来扣字眼。
: “一个用户态进程call一个系统调用，系统调用一定是在同一个CPU上直接执行。”
: 最后一个词，“执行”
: 这是一个动词。
: 前一个词，“直接”，immediately，表示动作是即时发生的。
|
t*****s
发帖数: 416 | 116
呵呵。thrust已经明确表示过他对我的话的翻译了。
http://www.mitbbs.com/article/Programming/31270577_0.html
显然不站在你的那一边。你以为这么低劣的一打一拉就可以轻松玩弄我们俩么。未免下
作而幼稚了。
说道这里你又提醒我还有个伤疤可以揭呢。
http://www.mitbbs.com/article/Programming/31270467_0.html
说起来倒是没看到人来帮你呢。当然了，赵C同学冒出来的话我是不会奇怪的。
【在 x****u 的大作中提到】
: 求你别侮辱我和thrust的智商了好不好！
: 对啊，显然你“是在描述call系统调用这个动作”，直接说任何x86的指令，都一定是
: 在“同一个CPU上直接执行”算了。
|
t****t
发帖数: 6806 | 117 求你别算我一份, 我觉得他说的我都能明白.
【在 x****u 的大作中提到】
: 求你别侮辱我和thrust的智商了好不好！
: 对啊，显然你“是在描述call系统调用这个动作”，直接说任何x86的指令，都一定是
: 在“同一个CPU上直接执行”算了。
|
x****u
发帖数: 44466 | 118 哈，那你真是令人失望了。
【在 t****t 的大作中提到】
: 求你别算我一份, 我觉得他说的我都能明白.
|
x****u
发帖数: 44466 | 119 thrust确实比你知道的太多了，所以说他可以说话而你只能骂啊。
【在 t*****s 的大作中提到】
:
: 呵呵。thrust已经明确表示过他对我的话的翻译了。
: http://www.mitbbs.com/article/Programming/31270577_0.html
: 显然不站在你的那一边。你以为这么低劣的一打一拉就可以轻松玩弄我们俩么。未免下
: 作而幼稚了。
: 说道这里你又提醒我还有个伤疤可以揭呢。
: http://www.mitbbs.com/article/Programming/31270467_0.html
: 说起来倒是没看到人来帮你呢。当然了，赵C同学冒出来的话我是不会奇怪的。
|
t****t
发帖数: 6806 | 120 别算我, 我是做硬件的, 所有的计算机课都没有上过.
【在 x****u 的大作中提到】
: thrust确实比你知道的太多了，所以说他可以说话而你只能骂啊。
|
|
|
x****u
发帖数: 44466 | 121 你上没上过课我不感兴趣，说的都是些常识的东西不需要上课也行。
【在 t****t 的大作中提到】
: 别算我, 我是做硬件的, 所有的计算机课都没有上过.
|
L***n
发帖数: 6727 | 122 对，我感觉是这样，扣一两个字眼没意思，这不是数学，如果能理解意思就没必要
扣个别词用法正确不正确
它们
【在 t****t 的大作中提到】
: 要我讲的话我觉得他说得没错, preemption不管在用户态还是内核态都有可能发生, 但
: 是系统调用本身是在同一个CPU上没错啊. 这两个基本上是正交的概念, 你为啥要把它们
: 混起来.
|
L***n
发帖数: 6727 | 123 是你在抬杠
【在 x****u 的大作中提到】
: 如果抬杠没意思了。调度器和普通task相比，CPU独立性更差你承认不？
:
: ,
|
s****y
发帖数: 104 | 124 看了诸位的讨论，奉劝楼主一句，别跟某些人一般见识了，没用的。免得气的自己伤身
。他爱喷一些没道理的东西，就让他喷好了，懂行的都会ignore他的
赞一下楼主写了这么好的长文跟大家分享关于系统设计方面的知识和对新方向的一些展
望，获益匪浅。楼主的这种帖子值得发扬光大，让更多的人受益。试问某人，你的那些
跟帖又为大家贡献了什么呢？本帖的标题是写给对系统感兴趣的人。某人既对系统一点
儿不感兴趣，又对系统最新知识不甚了解，干嘛要进来呢？就算是抱着想学习了解最新
知识的意愿进到这个帖子中，又干嘛以自己粗浅的了解和网上搜索的一些东西胡搅蛮缠
混淆视听呢？有意思吗？
术业有专攻。每个人都有热爱并为之努力的事业，某人想必年龄也不小了，难道就没有
学到对别人，对别人的事业的尊重嘛？难道就认为你学的就是宇宙真理，别人学的都是
一文不值的吗？ 如果你真是这么想的，那大家都别说啥了，你这种人心胸狭窄，容不
得人，在事业上也走不了多远，大家不值得跟他纠缠。如果你并不是这么想，只是话赶
话习惯性的想辩论过别人，争强好胜，奉劝你一句，有功夫可以在工作上更上一层楼，
别在网上花这么功夫绞尽脑汁跟专家辩论，又没奖金的说。 |
r*********r
发帖数: 3195 | 125 xiaoju 和 zhaoce 得都跳过不看就好了。 真心烦。 |
n******t
发帖数: 4406 | 126 我不知道你为啥要去扯kernel preemption的问题。
那东西就是一个patch.主要目的是为了降低latency。
这个和前面说的scheduler的功能原理没什么关系。
Linux Kernel N年都没有preemption也都好好的。
实际上我现在编译server kernel我也不用preemption.
我觉得你最好focus一个事情，否则根本说不清楚。
【在 x****u 的大作中提到】
: 拜托专业点好不好，这是驱动开发基本知识了。
: 如果在所有的内核代码里面都假定CPU不变，系统会当掉。内核里面如果不想被抢占，
: Linux或者NT都有自己的做法，也要付出代价。
: 当年Linux内核改抢占时，也是闹得鸡飞狗跳的。。。
:
: 料首
|
x****u
发帖数: 44466 | 127 给新手修正内核bug的时候，外人看起来的确很像抬杠。
【在 L***n 的大作中提到】
: 是你在抬杠
|
x****u
发帖数: 44466 | 128 举此例子是为了说明，代码即使进入内核空间也不见得在同一CPU上执行。依赖此特性
会导致隐蔽bug，因为毕竟大部分时间都在执行用户mode代码。几星期几个月崩溃一次
你怎么查？
【在 n******t 的大作中提到】
: 我不知道你为啥要去扯kernel preemption的问题。
: 那东西就是一个patch.主要目的是为了降低latency。
: 这个和前面说的scheduler的功能原理没什么关系。
: Linux Kernel N年都没有preemption也都好好的。
: 实际上我现在编译server kernel我也不用preemption.
: 我觉得你最好focus一个事情，否则根本说不清楚。
|
x****u
发帖数: 44466 | 129 这话千万不能在面试底层系统工作的时候说。。。
【在 L***n 的大作中提到】
: 对，我感觉是这样，扣一两个字眼没意思，这不是数学，如果能理解意思就没必要
: 扣个别词用法正确不正确
:
: 它们
|
t*****s
发帖数: 416 | 130 呵呵。
这个帖子开始就说了，第一，是写给对系统感兴趣的人看的。第二，不欢迎你。你那边
开钓鱼贴我也没理你。
结果您老不管不顾冲进来揪着就是一顿狂批，楞是把我关于未来系统发展的推测批了个
遍。
批就批吧，您要说的有道理我也能接受。
问题是每个问题没一俩回合您就接不上茬了。光顾着往我身上贴标签。
咱来数数都贴了些啥：
【机械劳动】【文学性，抒情的】【王垠翻版】【计死早】【无知小孩】【Google到】
你要贴标签也行。可是找你要标签的依据，比如什么【文学性】【王垠翻版】，你又不
接茬。
最后实在没办法了，把我的话截了一半出来开始扭曲原意，然后往【Google到】上靠。
thrust为人比较君子，说话的时候持中立态度，说我那个因为被你截了一半外加歪曲之
后的话显得有问题有两种可能，一种是我懒得说了，一种是我Google来的，但是他觉得
是前者。
你一看立马high了蹬鼻子上脸，说管我Google还是baidu来的，反正不是看原代码看来
的。
就你这么个套路，说你不要脸还真不算骂你。
再来说你揪着不放的“每个CPU上有一个scheduler”。就算这话不严谨好了。我后面也
立马仔细说明了。
http://www.mitbbs.com/article/Programming/31270487_0.html
里面说的很清楚。“每个CPU上有一个scheduler”的具体意义是每个CPU自己为自己
scheduling。想说我马后炮么？不好意思，这贴正好在你开始揪“每个CPU上有一个
scheduler”的楼上。
所以你揪了半天，其实什么也证明不了，顶多证明我语文没学精，玩弄文字不如你，偶尔
嘴上漏两个词会不严谨而已。
其实你语文又学得咋样呢？就你这么句话估计就要让你语文老师给你打个大红叉，然后
写上“多太多了”。
大家不愿意跟你一样low，讨论技术讨论到揪字眼的份上而已。 |
|
|
t*****s
发帖数: 416 | 131 另外谢谢楼上诸位兄弟的支持，大家眼睛还是雪亮的。
我就不一个一个re了。 |
x****u
发帖数: 44466 | 132 你刚说的“每个CPU自己为自己scheduling。”这句话是不正确的。我前面讲了，
scheduling是全局的事情，每次调度需要考虑别的CPU的状态。
【在 t*****s 的大作中提到】
: 呵呵。
: 这个帖子开始就说了，第一，是写给对系统感兴趣的人看的。第二，不欢迎你。你那边
: 开钓鱼贴我也没理你。
: 结果您老不管不顾冲进来揪着就是一顿狂批，楞是把我关于未来系统发展的推测批了个
: 遍。
: 批就批吧，您要说的有道理我也能接受。
: 问题是每个问题没一俩回合您就接不上茬了。光顾着往我身上贴标签。
: 咱来数数都贴了些啥：
: 【机械劳动】【文学性，抒情的】【王垠翻版】【计死早】【无知小孩】【Google到】
: 你要贴标签也行。可是找你要标签的依据，比如什么【文学性】【王垠翻版】，你又不
|
x****u
发帖数: 44466 | 133 赞！
【在 t*****s 的大作中提到】
: 另外谢谢楼上诸位兄弟的支持，大家眼睛还是雪亮的。
: 我就不一个一个re了。
|
t*****s
发帖数: 416 | 134 第一，就算“每次调度需要考虑别的CPU的状态。“这句话成立。依然是每个CPU自己给
自己scheduling，只不过scheduling的时候每个CPU会查询其他CPU的状态。所以你又再
试图引入一个新因素来证伪已有模型。
第二，麻烦你解释一下您的“全局”scheduling的运行机制吧。
【在 x****u 的大作中提到】
: 你刚说的“每个CPU自己为自己scheduling。”这句话是不正确的。我前面讲了，
: scheduling是全局的事情，每次调度需要考虑别的CPU的状态。
|
x****u
发帖数: 44466 | 135 “每个CPU会查询其他CPU的状态。”这句话仍然有错误。
实际上是scheduler是一个整体，维护了整个系统的CPU状态。每次单个CPU自陷时都会
执行同一段代码，通过统一的策略调度。
另外，你说说系统级如何实现“查询其他CPU的状态”？
【在 t*****s 的大作中提到】
: 第一，就算“每次调度需要考虑别的CPU的状态。“这句话成立。依然是每个CPU自己给
: 自己scheduling，只不过scheduling的时候每个CPU会查询其他CPU的状态。所以你又再
: 试图引入一个新因素来证伪已有模型。
: 第二，麻烦你解释一下您的“全局”scheduling的运行机制吧。
|
t*****s
发帖数: 416 | 136 呵呵。
“每个CPU会查询其他CPU的状态。”这句话是我对你所说的“每次调度需要考虑别的
CPU的状态。“的解读。
你说错了就错了。无所谓。
我就问你一个问题，最终一个CPU在进程调度的时候，调度的下一个进程是什么？这个
问题是在哪里解决的？
如果是在这个CPU本身上面。
那么"每个CPU自己给自己scheduling"就没有任何问题。
你一遍遍的强调“执行同‘一’段代码，通过统‘一’的策略调度”又有什么意义呢？
全世界运行同一个版本，同样参数编译的Linux的PC都是“执行同‘一’段代码，通过
统‘一’的策略调度”的呢。
你说维护了整个系统的CPU状态，不如展开讲讲这个状态具体指什么吧。
【在 x****u 的大作中提到】
: “每个CPU会查询其他CPU的状态。”这句话仍然有错误。
: 实际上是scheduler是一个整体，维护了整个系统的CPU状态。每次单个CPU自陷时都会
: 执行同一段代码，通过统一的策略调度。
: 另外，你说说系统级如何实现“查询其他CPU的状态”？
|
x****u
发帖数: 44466 | 137 SMP是多处理器通过软件或者硬件的锁，共享内存，IO和中断的并行技术。这种架构下
没有廉价的办法可以查询其它CPU的状态。
SMP的调度粗略的说和中断类似，每个CPU都执行自己的任务，在时间片用完后自陷到调
度器，根据算法换一个task，或者继续执行原有task。
因为没有办法直接知道别的CPU在做什么，只能通过内核数据结构配合锁获取。每个CPU
在内存里面都有一个执行队列，然后调度器要根据算法总体的调整所有的执行队列。
【在 t*****s 的大作中提到】
: 呵呵。
: “每个CPU会查询其他CPU的状态。”这句话是我对你所说的“每次调度需要考虑别的
: CPU的状态。“的解读。
: 你说错了就错了。无所谓。
: 我就问你一个问题，最终一个CPU在进程调度的时候，调度的下一个进程是什么？这个
: 问题是在哪里解决的？
: 如果是在这个CPU本身上面。
: 那么"每个CPU自己给自己scheduling"就没有任何问题。
: 你一遍遍的强调“执行同‘一’段代码，通过统‘一’的策略调度”又有什么意义呢？
: 全世界运行同一个版本，同样参数编译的Linux的PC都是“执行同‘一’段代码，通过
|
t*****s
发帖数: 416 | 138 “然后调度器要根据算法总体的调整所有的执行队列”
这个调度器在哪个CPU上运行？
CPU
【在 x****u 的大作中提到】
: SMP是多处理器通过软件或者硬件的锁，共享内存，IO和中断的并行技术。这种架构下
: 没有廉价的办法可以查询其它CPU的状态。
: SMP的调度粗略的说和中断类似，每个CPU都执行自己的任务，在时间片用完后自陷到调
: 度器，根据算法换一个task，或者继续执行原有task。
: 因为没有办法直接知道别的CPU在做什么，只能通过内核数据结构配合锁获取。每个CPU
: 在内存里面都有一个执行队列，然后调度器要根据算法总体的调整所有的执行队列。
|
x****u
发帖数: 44466 | 139 和其他代码一样，中断发生在哪里就在哪里执行。但这仅是执行，数据还是全体共享的。
CPU没有自己的私有数据区，内部状态也不可能廉价的共享给别的CPU。
【在 t*****s 的大作中提到】
: “然后调度器要根据算法总体的调整所有的执行队列”
: 这个调度器在哪个CPU上运行？
:
: CPU
|
t*****s
发帖数: 416 | 140 所以总结一下，您认为每个CPU都有各自的运行队列。然后scheduling的时候CPU不仅调
整自己的队列，还调整其他CPU的队列是么？
的。
【在 x****u 的大作中提到】
: 和其他代码一样，中断发生在哪里就在哪里执行。但这仅是执行，数据还是全体共享的。
: CPU没有自己的私有数据区，内部状态也不可能廉价的共享给别的CPU。
|
|
|
x****u
发帖数: 44466 | 141 队列指的是下一个任务，别人CPU当前任务轻易是动不了的。队列在内存里不在CPU里。
如何调整这个队列让所有CPU高效率运行，是调度算法的核心内容。
【在 t*****s 的大作中提到】
: 所以总结一下，您认为每个CPU都有各自的运行队列。然后scheduling的时候CPU不仅调
: 整自己的队列，还调整其他CPU的队列是么？
:
: 的。
|
t*****s
发帖数: 416 | 142
那么修改一下就是您认为每个CPU都有各自的运行队列。然后scheduling的时候CPU不仅
调整自己的“下一个任务”，还调整其他CPU的“下一个任务”是么？
【在 t*****s 的大作中提到】
: 所以总结一下，您认为每个CPU都有各自的运行队列。然后scheduling的时候CPU不仅调
: 整自己的队列，还调整其他CPU的队列是么？
:
: 的。
|
x****u
发帖数: 44466 | 143 当然。
我前面举过一个例子，当CPU调度时如果发现其他CPU队列空闲，应该把新任务让给别人
，自己尽可能执行同一任务。
这只是非常粗略的比喻，调度算法是OS研究的核心问题之一，细节上非常复杂。
【在 t*****s 的大作中提到】
:
: 那么修改一下就是您认为每个CPU都有各自的运行队列。然后scheduling的时候CPU不仅
: 调整自己的“下一个任务”，还调整其他CPU的“下一个任务”是么？
|
t*****s
发帖数: 416 | 144 唉，我又不忍心了。等thrust来纠正你吧。免得你又说我Google来的。
另外提醒您一句，“非常复杂”这个词可不是您惯常拿来形容系统的词呢。
http://www.mitbbs.com/article/Programming/31270223_0.html
【在 x****u 的大作中提到】
: 当然。
: 我前面举过一个例子，当CPU调度时如果发现其他CPU队列空闲，应该把新任务让给别人
: ，自己尽可能执行同一任务。
: 这只是非常粗略的比喻，调度算法是OS研究的核心问题之一，细节上非常复杂。
|
x****u
发帖数: 44466 | 145 开荒地细节上也非常复杂，但这些都是用人家的发明。
你自己写OS，99%的算法都是直接挪用的，创新剩下1%自创，不久之后也会被改错删掉
。这创新性连开荒都不如。
【在 t*****s 的大作中提到】
: 唉，我又不忍心了。等thrust来纠正你吧。免得你又说我Google来的。
: 另外提醒您一句，“非常复杂”这个词可不是您惯常拿来形容系统的词呢。
: http://www.mitbbs.com/article/Programming/31270223_0.html
|
t*****s
发帖数: 416 | 146 你给每个CPU写一个单独的scheduling队列，这样的创新当然要被删啦。
既然你要全局调整所有CPU的队列，那么跟全局就一个队列大家一起调整有什么区别？
每个CPU单独维护个队列操作起来多麻烦。
咦，好像全局就一个队列听起来很耳熟的样子……
当然耳熟了，我一直就这么跟你说的嘛。
【在 x****u 的大作中提到】
: 开荒地细节上也非常复杂，但这些都是用人家的发明。
: 你自己写OS，99%的算法都是直接挪用的，创新剩下1%自创，不久之后也会被改错删掉
: 。这创新性连开荒都不如。
|
x****u
发帖数: 44466 | 147 我又一次跟不上你逻辑了
【在 t*****s 的大作中提到】
: 你给每个CPU写一个单独的scheduling队列，这样的创新当然要被删啦。
: 既然你要全局调整所有CPU的队列，那么跟全局就一个队列大家一起调整有什么区别？
: 每个CPU单独维护个队列操作起来多麻烦。
: 咦，好像全局就一个队列听起来很耳熟的样子……
: 当然耳熟了，我一直就这么跟你说的嘛。
|
n******t
发帖数: 4406 | 148 依赖什么特性？
这事情不最先再聊就是一个系统调用用户态内核态的事情么？
trivial scheduler也能把问题说清楚的好不好？
【在 x****u 的大作中提到】
: 举此例子是为了说明，代码即使进入内核空间也不见得在同一CPU上执行。依赖此特性
: 会导致隐蔽bug，因为毕竟大部分时间都在执行用户mode代码。几星期几个月崩溃一次
: 你怎么查？
|
t****t
发帖数: 6806 | 149 小菊花同学喜欢把事情扯远, 你要容忍.
【在 n******t 的大作中提到】
: 依赖什么特性？
: 这事情不最先再聊就是一个系统调用用户态内核态的事情么？
: trivial scheduler也能把问题说清楚的好不好？
|
t****t
发帖数: 6806 | 150 2.4是全局队列没有错.
2.6核心确实每个CPU有自己的队列和锁, 另外有一个migration thread在每个CPU上跑,
做load balancing. 全局锁和全局队列已经没有了.
如果你说的纠正是指这个, 那他说的是对的.
【在 t*****s 的大作中提到】
: 唉，我又不忍心了。等thrust来纠正你吧。免得你又说我Google来的。
: 另外提醒您一句，“非常复杂”这个词可不是您惯常拿来形容系统的词呢。
: http://www.mitbbs.com/article/Programming/31270223_0.html
|
|
|
x****u
发帖数: 44466 | 151 你新警察不要跟着乱，NT搞内核抢占大概有20年了，Linux也有10年了，当年改的时候
都把驱动闹得鸡飞狗跳。
【在 n******t 的大作中提到】
: 依赖什么特性？
: 这事情不最先再聊就是一个系统调用用户态内核态的事情么？
: trivial scheduler也能把问题说清楚的好不好？
|
x****u
发帖数: 44466 | 152 你老id也这样说话真是让人失望。
【在 t****t 的大作中提到】
: 小菊花同学喜欢把事情扯远, 你要容忍.
|
t****t
发帖数: 6806 | 153 我已经说过了, 我只管说话, 不管听众想法.
【在 x****u 的大作中提到】
: 你老id也这样说话真是让人失望。
|
x****u
发帖数: 44466 | 154 这个我尊重，但对人不对事不好。
【在 t****t 的大作中提到】
: 我已经说过了, 我只管说话, 不管听众想法.
|
t****t
发帖数: 6806 | 155 对事不对人指的是不根据做事的人而对事情有什么不同的评价, 不等于说不能对人.
【在 x****u 的大作中提到】
: 这个我尊重，但对人不对事不好。
|
x****u
发帖数: 44466 | 156 我的意思是，应该发8区。
【在 t****t 的大作中提到】
: 对事不对人指的是不根据做事的人而对事情有什么不同的评价, 不等于说不能对人.
|
n******t
发帖数: 4406 | 157 so what???
【在 x****u 的大作中提到】
: 你新警察不要跟着乱，NT搞内核抢占大概有20年了，Linux也有10年了，当年改的时候
: 都把驱动闹得鸡飞狗跳。
|
x****u
发帖数: 44466 | 158 你用不着不等于别人不在乎啊。
因为新手搞不清类似的东西而捅出的篓子，很多时候需要花上几周才能精确定位。
【在 n******t 的大作中提到】
: so what???
|
t*****s
发帖数: 416 | 159 是么，我回去再看看去。
跑,
【在 t****t 的大作中提到】
: 2.4是全局队列没有错.
: 2.6核心确实每个CPU有自己的队列和锁, 另外有一个migration thread在每个CPU上跑,
: 做load balancing. 全局锁和全局队列已经没有了.
: 如果你说的纠正是指这个, 那他说的是对的.
|
n******t
发帖数: 4406 | 160 不要扯preemption,就说最先说的,明明就是个基本话题。用户内核态切换，
这东西严格来说和schedule也没什么直接关系,和SMP都没必然联系，和
preemption更没必然联系。你没事空立个靶子说别人不懂，我看不出来
这个point在哪里。
而且kernel preemption不是什么rocket science,
虽然的确需要很多技术手段去很好的实现,但是不懂kernel preemption
就不能做底层开发了？这不是扯淡么。
此外，kernel preemption也不是Linux的强项，
并且大部分server 都不需要kernel preemption。
最后我个人认为你这种做法非常无聊。自己没有建设性意见，
除了xxx没有前途，就yyy没有前途。你觉得什么有前途？
自己基本上没有干货，别人一说干货，你就无限制衍生话题，
直到别人有一些可能不是完全正确的观点出来，你就一整乱high，
真是闲的慌。
【在 x****u 的大作中提到】
: 你用不着不等于别人不在乎啊。
: 因为新手搞不清类似的东西而捅出的篓子，很多时候需要花上几周才能精确定位。
|
|
|
x****u
发帖数: 44466 | 161 “不懂kernel preemption就不能做底层开发了？”
很遗憾，为了地球和平请离底层越远越好。
NT下这个概念比Linux严格的多，要是完全无视内核抢占，系统天天BSOD。
【在 n******t 的大作中提到】
: 不要扯preemption,就说最先说的,明明就是个基本话题。用户内核态切换，
: 这东西严格来说和schedule也没什么直接关系,和SMP都没必然联系，和
: preemption更没必然联系。你没事空立个靶子说别人不懂，我看不出来
: 这个point在哪里。
: 而且kernel preemption不是什么rocket science,
: 虽然的确需要很多技术手段去很好的实现,但是不懂kernel preemption
: 就不能做底层开发了？这不是扯淡么。
: 此外，kernel preemption也不是Linux的强项，
: 并且大部分server 都不需要kernel preemption。
: 最后我个人认为你这种做法非常无聊。自己没有建设性意见，
|
n******t
发帖数: 4406 | 162 我问你，你这辈子写过几个系统应用是要用到内核抢占的？(如果你还写过）
你知道kernel premption是用来干什么的吧br />
P.S 本来我不想回你，看你这么喜欢NT这个东西，那玩意
在服务器上面和Linux 2.2都没得比。Linux 2.2可是和
kernel preemption一毛钱关系都没有。
【在 x****u 的大作中提到】
: “不懂kernel preemption就不能做底层开发了？”
: 很遗憾，为了地球和平请离底层越远越好。
: NT下这个概念比Linux严格的多，要是完全无视内核抢占，系统天天BSOD。
|
x****u
发帖数: 44466 | 163 你倒是好歹看点书再装业内人士啊。
不知道内核有抢占不等于抢占不存在，新手只会撑着脑袋骂，为什么这么简单几条指令
却总崩溃，肯定硬件故障。
Linux 2.2比NT差远了，Linux内核也就是2.6以后还凑合，以前的问题非常多。不支持
内核抢占影响GUI效率，对线程支持不好也严重影响JVM，在电源管理，IO方面也是bug
非常多。
NT这个东西，那玩意
【在 n******t 的大作中提到】
: 我问你，你这辈子写过几个系统应用是要用到内核抢占的？(如果你还写过）
: 你知道kernel premption是用来干什么的吧br />
: P.S 本来我不想回你，看你这么喜欢NT这个东西，那玩意
: 在服务器上面和Linux 2.2都没得比。Linux 2.2可是和
: kernel preemption一毛钱关系都没有。
|
t****t
发帖数: 6806 | 164 非常对, 小菊花的基本手段就是扯得很远直到别人出错为止, 然后说这个东西有多么重
要, 其实跟最初的事情毫无联系.
【在 n******t 的大作中提到】
: 不要扯preemption,就说最先说的,明明就是个基本话题。用户内核态切换，
: 这东西严格来说和schedule也没什么直接关系,和SMP都没必然联系，和
: preemption更没必然联系。你没事空立个靶子说别人不懂，我看不出来
: 这个point在哪里。
: 而且kernel preemption不是什么rocket science,
: 虽然的确需要很多技术手段去很好的实现,但是不懂kernel preemption
: 就不能做底层开发了？这不是扯淡么。
: 此外，kernel preemption也不是Linux的强项，
: 并且大部分server 都不需要kernel preemption。
: 最后我个人认为你这种做法非常无聊。自己没有建设性意见，
|
L***n
发帖数: 6727 | 165 这游戏无聊的很，我宁愿看一行代码也不想看扯蛋
【在 t****t 的大作中提到】
: 非常对, 小菊花的基本手段就是扯得很远直到别人出错为止, 然后说这个东西有多么重
: 要, 其实跟最初的事情毫无联系.
|
t****t
发帖数: 6806 | 166 对, 就是这样---就算天天BSOD, 跟切换用户内核态有一毛钱关系吗?
【在 x****u 的大作中提到】
: “不懂kernel preemption就不能做底层开发了？”
: 很遗憾，为了地球和平请离底层越远越好。
: NT下这个概念比Linux严格的多，要是完全无视内核抢占，系统天天BSOD。
|
x****u
发帖数: 44466 | 167 喂喂，8区出门左转。
【在 t****t 的大作中提到】
: 非常对, 小菊花的基本手段就是扯得很远直到别人出错为止, 然后说这个东西有多么重
: 要, 其实跟最初的事情毫无联系.
|
x****u
发帖数: 44466 | 168 “kernel preemption”中文不叫“切换用户内核态”，回错贴了么？
如果没回错贴的话，查查BSOD 0x0A：IRQL_NOT_LESS_OR_EQUAL是什么意思，和“
kernel preemption”有没有关系。
【在 t****t 的大作中提到】
: 对, 就是这样---就算天天BSOD, 跟切换用户内核态有一毛钱关系吗?
|
H**r
发帖数: 10015 | 169 哈哈
【在 t****t 的大作中提到】
: 非常对, 小菊花的基本手段就是扯得很远直到别人出错为止, 然后说这个东西有多么重
: 要, 其实跟最初的事情毫无联系.
|
p*u
发帖数: 2454 | 170
i hate 2 say this, but can u just shut up or go away?
【在 x****u 的大作中提到】
: “kernel preemption”中文不叫“切换用户内核态”，回错贴了么？
: 如果没回错贴的话，查查BSOD 0x0A：IRQL_NOT_LESS_OR_EQUAL是什么意思，和“
: kernel preemption”有没有关系。
|
|
|
x****u
发帖数: 44466 | 171 您老连epoll is much more scalable then thread pool都敢说，还有脸骂街？
【在 p*u 的大作中提到】
:
: i hate 2 say this, but can u just shut up or go away?
|
p*u
发帖数: 2454 | 172
my bad, shouldnt even bother replying to u.
【在 x****u 的大作中提到】
: 您老连epoll is much more scalable then thread pool都敢说，还有脸骂街？
|
l*****t
发帖数: 2019 | 173 一个EE改行过来搞CS，能写出这些个东西算高手了.
【在 x****u 的大作中提到】
: 你这个同学对CS的认识，除了几个机械劳动的领域外，剩下的全都是些文学性，抒情的
: 东西。
: 把最后那一段每个奇怪的念头拿出来单发一贴，咱们可以讨论一下为什么不靠谱。
|
n******t
发帖数: 4406 | 174 嗯，要忍住不回他的贴有时候还是有难度的。
【在 t****t 的大作中提到】
: 非常对, 小菊花的基本手段就是扯得很远直到别人出错为止, 然后说这个东西有多么重
: 要, 其实跟最初的事情毫无联系.
|
x****u
发帖数: 44466 | 175 小同学，这是近20年前烂大街的面试题。。。
【在 p*u 的大作中提到】
:
: my bad, shouldnt even bother replying to u.
|
t****t
发帖数: 6806 | 176 这个就叫对人不对事--因为他说过什么什么, 所以不能有脸骂街.
要不要我把你以前多线程那个贴翻出来?
【在 x****u 的大作中提到】
: 您老连epoll is much more scalable then thread pool都敢说，还有脸骂街？
|
t*****s
发帖数: 416 | 177 +1
小菊花同学天天逮着机会就开钓鱼贴黑我。有时候黑的太jian就算知道是钓鱼贴也很难
忍住啊。
【在 n******t 的大作中提到】
: 嗯，要忍住不回他的贴有时候还是有难度的。
|
x****u
发帖数: 44466 | 178 混了这么多年了还这么说话真是丢人
【在 t****t 的大作中提到】
: 这个就叫对人不对事--因为他说过什么什么, 所以不能有脸骂街.
: 要不要我把你以前多线程那个贴翻出来?
|
t****t
发帖数: 6806 | 179 来来回回只会说这么一句才是丢人.
【在 x****u 的大作中提到】
: 混了这么多年了还这么说话真是丢人
|
x****u
发帖数: 44466 | 180 我不怎么写C++所以回你贴机会不多，不过几年前确实有一次多人争论，涉及到
volatile关键字在多线程优化时下意义的。
当时的确不明白你为什么非常执着的要把lock机制牵涉进来，这本来是另外一个话题。
现在有点明白了。
【在 t****t 的大作中提到】
: 来来回回只会说这么一句才是丢人.
|
|
|
o******2
发帖数: 15 | 181 都是大牛啊。。。
我最近在学操作系统，有没有什么好的书推荐呢？
直接看源代码不知到从哪里看起？ |
k**********g
发帖数: 989 | 182
http://stackoverflow.com/questions/1848029/why-not-port-linux-k
【在 o******2 的大作中提到】
: 都是大牛啊。。。
: 我最近在学操作系统，有没有什么好的书推荐呢？
: 直接看源代码不知到从哪里看起？
|
l*****i
发帖数: 13 | 183 <操作系统概念>，<现代操作系统>
我的体会是，如果还在看原理书的阶段，就别看源代码超过200K的操作系统代码。超过
了这个数量级，绝大部分代码解决的事情已经不是“原理”了，对初学者几乎谈不上什
么好处，经常纠结于实现而忽略了原理。
当你可以抛开书的时候，倒是可以开始看实现，随便抠出来个什么模块，如果看懂了就
对自己提高蛮大的。
这是我这小P的经验，希望对你有帮助
【在 o******2 的大作中提到】
: 都是大牛啊。。。
: 我最近在学操作系统，有没有什么好的书推荐呢？
: 直接看源代码不知到从哪里看起？
|
