《关于新一代操作系统的思考》

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享

(7个打分, 平均:3.43 / 5)

包云岗 。《科研指挥棒怎么挥舞》

(没有打分)

魏永明 。 “自主”操作系统 (完)

4 如何开发“自主”操作系统

4.1 开发“自主”操作系统的两种目的和策略

开发“自主”操作系统的主要目的有两种:一种是想再造一个类似 Android、iOS 的操作系统,并作为其竞争者;一种仅仅是为了在商务谈判和合作中获得一个比较好的筹码。当然,还有一种目的就是骗取政府的财政支持,对这类不良目的,不属本文讨论范围。

我们先猜度一下国内外这几年出现的一些“自主”操作系统,其目的是什么:

  • 中国移动通过博思通讯开发的 OMS。本质上 OMS 是 Android 的一个派生系统。很明显,中国移动开发 OMS 的目的属于前一种。中国移动希望利用自己强大的市场地位来左右手机供应商的 OS 选择,并建立起类似苹果那样的全封闭的平台和生态系统。可惜的是,OMS 并没有取得预期效果,在来自联通、电信的强大市场压力下,中国移动不得不允许 TD 手机使用正统的 Android 系统;OMS 也正在被市场淡忘。这里有个比较有意思的现象,Google 从来没有公开质疑过 OMS 系统,阿里 OS 的做法和 OMS 类似,却遭到了打压。这里有两个原因,一个是中国移动的市场地位摆在那里(加上还是巨型国企),Google 不敢轻举妄动,另外一个是 OMS 采用的是 Android 早期版本,那时候 Android 的市场地位还没有这么强。
  • 中国联通所谓的 UniPlus。可惜的是,UniPlus 似乎从来没有面过世,也许中国联通只是放了一个烟雾弹而已。要是真开发,目的自然应该和中国移动的 OMS 类似。
  • Firefox OS。这是 Mozilla 公司推出的纯粹基于 HTML5/CSS3/JavaScript 等网页前端开发技术推出的操作系统,和 HP 收购自 Palm 的 webOS 有类似的软件架构。HP 收购了 webOS 之后的半年,即宣告放弃 webOS,而 Mozilla 却希望通过类似技术的 Firefox OS 成为 Android 的竞争者。一会儿我们分析下为什么 Firefox OS 要比 webOS 有更强一些的生命力。
  • 华为提出要开发的“自主”操作系统。作为一个智者,任正非不可能不知道一个真正“自主”的操作系统应该是什么样子的。华为就算再有钱,再有人才,短时间内也是搞不定一个“自主”操作系统的(如前所述,主要是建立对应的生态系统太难了)。这么说来,华为开发“自主”操作系统,其目的其实就是做一个备胎,以便在和 Android、Windows Phone 等合作时能够有一个可以讨价还价的砝码。也就是说,华为并不是真的要做“自主”的操作系统;或者这么说,支持团队去做,做成 Android 那样最好,做不成 Android 那样,如果真有一天打起架来可以凑合用也行。
  • 阿里 OS。马云同志的野心很大,他做阿里 OS,就是要复制 Google 在移动互联网的商业模式,进而在移动互联网领域推广阿里体系的服务和内容。可惜的是,马云貌似不太懂技术,也没个明白人给他做参谋,结果被人害了,花了钱还被人捏住了七寸。最新的传言,说阿里 OS 要换将,继续再投个 2 亿搞。马云同志啊,光有钱是不行的,你身边还得有个把技术大牛帮你把关、出谋划策才行啊。

好,面对这两种开发“自主”操作系统的目的,应该有什么样的策略呢?其实策略很简单,不管你是真心还是假意,都应该按照本文第 3 章给出的“自主”操作系统之特征进行开发,除此之外,别无他法。任何期望找捷径的方法,都不可能获得成功。这里所说的找捷径的方法具体有:

  • 给 Android 整容。如 OMS、阿里 OS。
  • 忽略操作系统之生态系统的重要性,在 Linux 或其他开源操作系统内核、系统库等基础上包裹一个简单的框架而形成的操作系统。这种操作系统,其复杂度和 Linux 发行版相当,离本人定义的真正“自主”操作系统还差十万八千里。读者可能会问,这样的系统做备胎不是还行吗?为什么也得按照真做那样开发呢?你要知道的是,对手也不是傻子,人家看你的架势,就知道你不是真做——你起码得拉出真做的架势来,人家才能怕你啊!

顺便谈谈我对基于浏览器技术的 web 操作系统之看法。

理论上讲,浏览器可以做很多事情,甚至可以替代 PC 机上的通用操作系统。但是,最新的浏览器技术(HTML5/CSS3等),还存在一些技术上的问题。主要的问题有如下两个:

  1. 浏览器主要采用的 JavaScript 编程语言,本质上是一种难于管理(源代码保护、无法进行有效的软件架构设计、难于调试等等)的编程语言,同时内存消耗巨大,性能不佳。最新的说法是,Facebook 创始人直言全面采用 HTML5 的策略是个失误,正在向操作系统的原生应用转移。也就是说,JavaScript 语言难以承载一个良性发展的生态系统。
  2. 因为许多原因(主要是利益和政治因素),HTML5 相关的标准有分裂的迹象,同时进展缓慢。

HTML5 技术作为原生应用的一种补充,可以起到很好的作用,但是,如果要想在浏览器技术上建立一个真正可以和 Android 等竞争的操作系统,恐怕还需要很长的时间(技术上必须有突破)。要不然,Google 现在主推的应该是 ChromeOS,而不是 Android。

现在回答刚才提到的问题:“为什么 FirefoxOS 可以比 webOS 的生命力更加长久些呢?”主要的原因是,FirefoxOS 是开源的,有比较强大的企业在主导其发展,作为一个脱胎于开源基金会的企业(Mozilla公司),也能获得合作伙伴的一些好感;相反,因为 webOS 是封闭,HP 又没有能力像苹果那样打造一个完全封闭的平台和生态系统,所以最终的命运是被人抛弃了。虽然后来 webOS 也走上了开源的道路,但大势已去,HP 不亲自带头搞,光靠开源社区是搞不成的。

4.2 技术层面上的考虑

假定你是一名“自主”操作系统项目的技术管理者,你第一步要考虑的问题是什么?许多人的回答可能是:先选操作系统内核、基础库什么的。其实错了,第一步要考虑的应该是你打算选择什么编程语言作为原生应用的编程语言。

世界上的编程语言有很多种,有些语言贴近机器,比如汇编语言、C语言,有些语言贴近人,比如 Basic、Java,还有些语言用于特定领域,比如网页服务器端使用的 PHP,有些适合做不同软件之间的粘合剂,比如 Perl、Python。本文第 3 章已经解释了编程语言以及围绕编程语言形成的运行环境、框架是将操作系统区隔于其他操作系统的主要技术特征。因此,我们必须慎重选择一种编程语言。而且一旦选定了一种编程语言,“自主”操作系统在开发者看来长什么样,其实就基本上定了。

选择编程语言要考虑如下因素:

  • 这种编程语言是否易于学习和掌握?是否有庞大的开发者在使用它?
  • 这种编程语言是否具有高级语言的基本特征,比如,支持面向对象编程?
  • 这种编程语言是否是编译执行的?
  • 这种编程语言是否利于保护开发者的知识产权?
  • 这种编程语言是否有完整的工具链支持?
  • 这种编程语言是否有集成开发环境的支持?
  • 这种编程语言是否易于保护整个操作系统不会被恶意代码轻易破坏?
  • 如此等等。

其实很多读者看到这里,都会想到 Java 语言。是的,Java 语言或其派生语言如 C# 是构架“自主”操作系统的最佳编程语言。可惜,已经被 Android 和 Windows Phone 给捷足先登了。

如此一来,你可以考虑重新设计一门类似 Java 的语言,也可以通过其他手段,让你使用 Java 语言构建的操作系统有别于其他操作系统。比如,构建自己的虚拟机,如 Android 使用的 Dalvik 那样(Dalvik 和 Oracle 的 JDK 标准虚拟机有很大不同,从而让 Oracle 还挺难告赢 Google 的);你也可以用 Dalvik,但让类库、运行环境和 Android 不同(这样做的法律风险要大一些)。总之,你需要有自己的创新,全部抄袭是不行的。

确定了编程语言,接下来的工作其实就比较直接了,从上而下设计就是了。主要有:

  1. 定义和实现提供给原生应用程序的基础 API 和/或虚拟机。
  2. 在应用程序基础 API、标准 C/C++ 函数库和相关组件(通常都是开源软件)的基础上构建操作系统的运行环境和框架。主要涉及系统服务、模块之间的通讯机制,包括图形界面、浏览器引擎、OpenGL ES 支持接口等等。
  3. 同时选择操作系统内核,通常也就是 Linux,要与众不同,用 BSD 也行。
  4. 搞定集成开发环境和模拟器,让开发者可以在 PC 机上为你的操作系统开发应用程序。
  5. 让你的操作系统运行在真实硬件上,为开发者提供应用样例和文档。
  6. 持续迭代,让你的“自主”操作系统不停往前发展。

上面的第一点和第二点,是“自主”操作系统有别于其他操作系统,且支撑你可以和其他人竞争的关键点。往下的东西都不是构成“自主”操作系统真正竞争力的东西。

这么看来,其实也挺简单的。不是吗?貌似有钱、有个把技术上的明白人就能做到。技术上没问题了,市场、法律等方面的事情,请专业人员帮忙,中国这类人才还是蛮多的,缺的,其实还是技术人员以及懂系统工程和软件开发的管理人员。

4.3 快速搭建一个“自主”操作系统

这里给大家介绍笔者早先和美国一家公司合作,尝试搭建的一个操作系统,其实在当年这些东西的基础上,搭建出来一个有别于 Android 的开源“自主”操作系统还是非常快的。

这个系统使用了 Linux 内核和标准的 C/C++ 函数库,以及一些和 Android 体系结构类似的 C/C++ 运行库,使用了笔者公司的开源软件 MiniGUI、WebKit 浏览器核心引擎等等。基础的东西就这些。之上是开源的 Kaffe JVM(后来改成了 Cacao JVM),和符合 J2SE 规范的类库实现,再往上就是运行环境和框架了。见下图:

可惜的是,真正具有核心价值的运行环境和框架,是美国合作方自己开发的,我手里没有源代码。相信读者也能明白,美国合作方掌握的才是精华。

阅读全文»

(15个打分, 平均:4.47 / 5)

淘宝网内核开发团队盼寻有缘分的在校实习生

淘宝内核组是一只非常年轻的队伍,我们作为开源社区和淘宝的桥梁,一方面基于淘宝的工作负载来改进Linux内核的性能和质量,另一方面也将开源社区的新想法引入到淘宝的操作系统运行环境中。我们在不断改进Linux在淘宝成千上万台服务器上运行的性能和稳定性的同时,也持续努力将我们的工作反馈回开源社区。

关于淘宝内核组的简单情况介绍,可以在这个wiki页面看到:http://kernel.taobao.org

对于我们在内核社区的一些还很初级的工作,在这个wiki页面有一些简单的数字:http://kernel.taobao.org/index.php/Documents/kernel_development_at_taobao

我们和国内、国际的同行一直有紧密的合作,同时我们的工作内容对开源社区也非常开放。在这个小团队工作,可以同我们一起体验如何从线上运行的上万台服务器的实际运行数据中寻找可以改进Linux内核的想法,然后付诸实践并通过实际运行数据来验证自己的工作效果,并最终将代码反馈回内核社区的这个过程。

如果你是在校的学生,对系统软件开发有一些了解,而且有热情投入到Linux内核开发的社区中来,也许你可以考虑加入到淘宝内核组这个小团体中来进行实习工作。我们是非常年轻的团队,但是我们是勤奋、认真和努力的一小撮人。

实习的工作地点在杭州或者北京的淘宝办公室,根据大家的意向而定;工作时间要求不短于3个月,每周不少于3天。我们的实习工资很平常,够路费和伙食费。只是希望在这里做过实习工作的同学以后回忆起这段经历会依然感觉很开心。

欢迎有兴趣的同学发邮件到 bosong.ly 在 taobao 点 com ,希望我们能够有缘分在一起度过一段值得回忆的时光。

P.S. 如果同学们毕业之后,不论是否加入淘宝的工程团队,只要能够兴趣参与到Linux内核开发和开源社区中来,这个实习生计划就是成功的。

(4个打分, 平均:4.75 / 5)

淘宝开源的PB级分布式数据库系统OceanBase简介

[ 编者注: OceanBase是一个支持海量数据的高性能数据库系统,实现了数千亿条记录、数百TB数据上的跨行跨表事务,由淘宝网核心系统研发部、运维、DBA、广告、应用研发等部门共同完成。其源代码已于8月31日遵照GPL2开源。

本文第一部分转载于淘宝网核心系统研发部博客, 原始链接位于http://rdc.taobao.com/blog/cs/?p=956

第二部分转载于OceanBase主程序员杨传辉同志的个人博客 , 原始链接位于 http://www.nosqlnotes.net/archives/tag/oceanbase

OceanBase的源码可于http://code.taobao.org/project/view/587/ 处得到]

OceanBase是什么

OceanBase是一个支持海量数据的高性能数据库系统,实现了数千亿条记录、数百TB数据上的跨行跨表事务,由淘宝核心系统研发部、运维、DBA、广告、应用研发等部门共同完成。

OceanBase解决什么问题

许多公司的核心资产是各种各样的商业数据,例如淘宝的商品、交易、订单、购物爱好等等,这些数据通常是结构化的,并且数据之间存在各种各样的关联,传统的关系数据库曾经是这些数据的最佳载体。然而,随着业务的快速发展,这些数据急剧膨胀,记录数从几千万条增加到数十亿条,数据量从百GB增加到数TB,未来还可能增加到数千亿条和数百TB,传统的关系型数据库已经无法承担如此海量的数据。许多公司,尤其是互联网公司,正在探索各自的解决之路。
一个思路是通过类似map-reduce模型进行处理,例如Google的 GFS+MapReduce以及Hadoop的HDFS+MapReduce。这类方式为离线数据处理及挖掘提供了一个不错的选择,但难以满足在线实时服务系统的需求。
另一个思路降低一致性来换取数据规模,例如BigTable和HBase实现了单行事务的海量数据的存储访问,Amazon的Dynamo以及由Facebook开源的Cassandra实现了最终一致性,这类系统常常被称为NoSQL数据库,它们在一些网站(例如Google,Facebook和Twitter等)得到了应用。
一个新近出现的系统是Google的Percolator,它在GFS/BigTable基础上实现了海量数据(PB级)的分布式事务。由于Google并没有把Percolator开源,其他公司无法使用它,此外事务响应时间偏长(平均2s-5s)以及单机效率低(Google声称Percolator的效率大致为DBMS的1/30)也限制了Percolator的使用(更多信息,请参见Daniel Peng和Frank Dabek的“Large-scale Incremental Processing Using Distributed Transactions and Notifications”一文)。
从Eric Brewer教授的CAP(一致性C: Consistency, 可用性A: Availability,分区容错性P: Tolerance of network Partition)理论来看,第一种思路重点在于支持CP特性,第二种思路重点在于支持AP特性。作为电子商务企业,淘宝和其他公司的业务对一致性和可用性的要求高于分区容错性,数据总量庞大且逐步增加,单位时间内的数据更新量并不大,但实时性要求很高。这些需求建议我们提供一套更加偏重于支持CA特性的系统,同时兼顾可分区性,并且在实时性、成本、性能等方面表现良好。

OceanBase的一些基本概念

OceanBase逻辑架构简图

主键

row key,也称为primary key,类似于DBMS的主键,与DBMS不同的是,OceanBase的主键总是二进制字符串(binary string),但可以有某种结构。OceanBase以主键为顺序存放表格数据

sstable

一种数据存储格式,OceanBase用来存储一个或几个表的一段按主键连续的数据

tablet

一个表按主键划分的一个(前开后闭的)范围,通常包含一个或几个sstable,一个tablet的数据量通常在256MB左右

基准数据和动态数据

OceanBase以增量方式记录一段时间内的表格数据的增删改,从而保持着表格主体数据在一段时间内相对稳定,其中增删改的数据称为动态数据(通常在内存,也称为内存表),而一段时间内相对稳定的主体数据称为基准数据,基准数据和转储后(保存到SSD固态盘或磁盘)的动态数据以sstable格式存储

ChunkServer

保存基准数据的服务器,通常是多台,为了避免软件硬件故障导致的服务中断,同一份基准数据通常保存了3份并存储在不同ChunkServer上

UpdateServer

保存动态数据的服务器,一般是单台服务器。为了避免软件硬件故障导致的服务中断,UpdateServer记录commit log并通常使用双机热备

MergeServer

进行静态动态数据合并的服务器,常常与ChunkServer共用一台物理服务器。MergeServer使得用户能够访问到完整的最新的数据

RootServer

配置服务器,一般是单台服务器。为了避免软件硬件故障导致的服务中断,RootServer记录commit log并通常采用双机热备。由于RootServer负载一般都很轻,所以它常常与UpdateServer共用物理机器

冻结

指动态数据(也称为内存表)的更新到一定时间或者数据量达到一定规模后,OceanBase停止该块动态数据的修改,后续的更新写入新的动态数据块(即新的内存表),旧的动态数据块不再修改,这个过程称为冻结

转储

出于节省内存或者持久化等原因将一个冻结的动态数据块(内存表)持久化(转化为sstable并保存到SSD固态盘货磁盘上)的过程

数据合并(merge)

查询时,查询项的基准数据与其动态数据(即增删改操作)合并以得到该数据项的最新结果的过程。此外,把旧的基准数据与冻结的动态数据进行合并生成新的基准数据的过程也称为数据合并

联表(join)

一张表与另一张或几表连接的关系,类似于DBMS的自然连接

COW

Copy on Write的缩写,在OceanBase中特指BTree在更新时复制数据备份写入,避免系统锁的技术手段

OceanBase有什么特点

OceanBase设计和实现的时候暂时摒弃了许多不需要的DBMS的功能,例如临时表,视图(view),SQL语言支持等,这使得研发团队能够把有限的资源集中到关键的功能上,例如数据一致性、高性能的跨表事务、范围查询、join等。
虽然数据总量比较大,但跟许多行业一样,淘宝业务一段时间(例如小时或天)内数据的增删改是有限的(通常一天不超过几千万次到几亿次),根据这个特点,OceanBase把一段时间内的增删改等修改操作以增量形式记录下来(称之为动态数据,通常保存在内存中),这样也使得了主体数据在一段时间内保持了相对稳定(称之为基准数据)。
由于动态数据相对较小,通常情况下,OceanBase把它保存在独立的服务器UpdateServer的内存中。以内存保存增删改记录极大地提高了系统写事务的性能。此外,假如每条修改平均消耗100 Bytes,那么10GB内存可以记录100M(即1亿)条修改,且扩充UpdateServer内存即增加了内存中容纳的修改量。不仅如此,由于冻结后的内存表不再修改,它也可以转换成sstable格式并保存到SSD固态盘或磁盘上。转储到SSD固态盘后所占内存即可释放,并仍然可以提供较高性能的读服务,这也缓解了极端情况下UpdateServer的内存需求。为了应对机器故障,动态数据服务器UpdateServer写commit log并采取双机(甚至多机)热备。由于UpdateServer的主备机是同步的,因此备机也可同时提供读服务。
因为基准数据相对稳定,OceanBase把它按照主键(primary key,也称为row key)分段(即tablet)后保存多个副本(一般是3个)到多台机器(ChunkServer)上,避免了单台机器故障导致的服务中断,多个副本也提升了系统服务能力。单个tablet的尺寸可以根据应用数据特点进行配置,相对配置过小的tablet会合并,过大的tablet则会分裂。
由于tablet按主键分块连续存放,因此OceanBase按主键的范围查询对应着连续的磁盘读,十分高效。
对于已经冻结/转储的动态数据,OceanBase的ChunkServer会在自己不是太繁忙的时候启动基准数据与冻结/转储内存表的合并,并生成新的基准数据。这种合并过程其实是一种范围查询,是一串连续的磁盘读和连续的磁盘写,也是很高效的。
传统DBMS提供了强大的事务性、良好的一致性和很短的查询修改响应时间,但数据规模受到严重制约,缺乏扩展性;现代云计算提供了极大的数据规模、良好的扩展性,但缺乏跨行跨表事务、数据一致性也较弱、查询修改响应时间通常也较长,OceanBase的设计和实现融合了二者的优势:

  1. UpdateServer:类似于DBMS中的DB角色,提供跨行跨表事务和很短的查询修改的响应时间以及良好的一致性
  2. ChunkServer:类似于云计算中的工作机(如GFS的chunk server),具有数据多副本(通常是3)、中等规模数据粒度(tablet大小约256MB)、自动负载平衡、宕机恢复、机器plug and play等特点,系统容量及性能可随时扩展
  3. MergeServer:结合ChunkServer和UpdateServer,获得最新数据,实现数据一致性
  4. RootServer:类似于云计算中的主控机(如GFS master),进行机器故障检测、负载平衡计算、负载迁移调度等

上述的DBMS和云计算技术的优势互补使得OceanBase既具有传统DBMS的跨行跨表事务、数据的强一致性以及很短的查询修改响应时间,还有云计算的海量数据管理能力、自动故障恢复、自动负载平衡以及良好的扩展性。

OceanBase现在有什么应用

OceanBase现在已经应用于淘宝收藏夹,用于存储淘宝用户收藏条目和具体的商品、店铺信息,每天支持4~5千万的更新操作。后续将陆续推广至其他淘宝应用。

OceanBase的创新之处在哪里?

ppt已上传到Slideshare上。

从大学的数据结构课程可以知道,数据量比较大时,有两种数据结构很常用:哈希表和B+树,分布式系统也是类似的。如下图:

云存储系统.png

Amazon的系统实现了一个分布式哈希表,而Google Bigtable, Yahoo PNUTS,Microsoft SQL Azure实现了一颗分布式B+树。分布式哈希表实现相对简单,但只支持随机读取;而分布式B+树支持范围查询,但实现比较复杂,主要有两个难点:

1, 状态数据的持久化和迁移。更新操作改变系统的状态,数据库系统中更新操作首先以事务提交日志(MySQL称为binlog, NOSQL称为commit log)写入到磁盘,为了保证可靠性,commit log需要复制多份并保证它们之间的一致性。另外,机器宕机时需要通过commit log记录的状态修改信息将服务迁移到集群中的其它节点。

2, 子表的分裂和合并。B+树实现的难点在于树节点的分裂与合并,在分布式系统中,数据被顺序划分为大小在几十到几百MB大小的数据范围,一般称为子表,相当于B+树结构中的叶子节点。由于每个子表在系统中存储多份,需要保证多个副本之间的分裂点是一致的。由于子表在分裂的同时也有更新操作,保证多个副本之间一致是比较困难的。

对于这两个问题,不同的系统有不同的解决方法:

1, 状态维持。Google Bigtable将状态数据写入到GFS中,由GFS提供可靠性保证,但GFS本身是一个巨大的工程;Yahoo PNUTS将状态数据写入到分布式消息中间件,Yahoo内部称为Yahoo Message Broker;Microsoft SQL Azure直接通过网络将数据复制到多机,由于一台机器服务多个子表,这些子表的副本可能分布在整个集群中,因此,任何两台机器都可能建立数据复制的网络通道,需要处理与这些通道有关的异常情况。

2, 子表分裂。由于底层有GFS保证可靠性,Google Bigtable设计时保证每一个子表同时只被一台机器(Tablet Server)服务;Yahoo PNUTS通过引入复杂的两节点提交(Two-phase commit)协议协调多个副本之间的一致性,使得他们的分裂点相同;Microsoft SQL Azure干脆不支持子表分裂,牺牲一部分扩展性从而简化系统设计。

淘宝Oceanbase设计之初对淘宝的在线存储需求进行分析发现:淘宝的数据总量比较大,未来一段时间,比如五年之内的数据规模为百TB级别,千亿条记录,另外,数据膨胀很快,传统的分库分表对业务造成很大的压力,必须设计自动化的分布式系统;然而,在线存储每天的修改量很小,大多数情况下单机的内存就能存放下。因此,我们采用将动态数据和静态数据分离的办法。动态数据的数据量小,采用集中式的方法解决,这样,状态数据维持从一个分布式的问题转化为单机的问题;静态数据的数据量大,采用分布式的方法解决,因为静态数据基本不变,实现时不需要复杂的线程同步机制,另外,保证静态数据的多个副本之间一致性是比较容易的,简化了子表的分裂和合并操作。通过这样的权衡,淘宝Oceanbase以一种很简单的方式满足了未来一段时间的在线存储需求,并且还获得了一些其它特性,如高效支持跨行跨表事务,这对于淘宝的业务是非常重要的。另外,我们之所以敢于做这样的权衡,还有一个重要的原因:我们内部已经思考了很多关于动态数据由集中式变为分布式的方案,即使我们对需求估计有些偏差,也可以很快修改原有系统进一步提高可扩展性。

(6个打分, 平均:4.67 / 5)

Java 程序的编译,加载 和 执行

[ 在这个 slides 里边, 莫枢 (Kris Mok) 介绍了 java & java run-time system 的结构。Managed language 提供了更高一级的抽象,提高了程序员的生产力,但是从 application code 到  ISA 的中间层也更厚,比如程序员非常容易把C代码对应到优化后的汇编,但是判断出java 程序对应的汇编就相对难一些。胶片作者的blog 是 http://rednaxelafx.iteye.com ]

(8个打分, 平均:4.38 / 5)

弯曲学术:Steve Blackburn 在清华的讲座

(Steve 去北京旅游,我忽悠他去清华 give a talk, 有兴趣的朋友欢迎来围观。)

Steve Blackburn 4 月 29 号上午9:50~12:00,在清华 FIT楼 1-312 会议室 give a talk。

谁是 Steve Blackburn?

Stephen Blackburn is an Associate Professor in the Department of Computer Science at Australian National University (http://users.cecs.anu.edu.au/~steveb/).  His research focus is on programming language implementation, and in particular the performance of modern programming languages on modern architectures.  He is interested in understanding, measuring and addressing the narrowing memory bottleneck, and the characteristics of modern languages and architectures that exacerbate this problem.  His service includes program committees and external review committees such as ASPLOS, ISCA, OOPSLA, ISMM, VEE, and PLDI, and the program chair of ISMM 2008.  He has led the development tools and benchmarks in wide use: the MMTk garbage collection toolkit and the DaCapo Java Benchmarks. He is on the Jikes RVM Steering committee and leads the DaCapo Benchmark Suite consortium.

他会讲神马?

Title: Looking Back on the Language and Hardware Revolutions: Measured
Power, Performance, and Scaling

Abstract:

This talk reports and analyzes measured chip power and performance on five
process technology generations executing 61 diverse benchmarks with a
rigorous methodology. We measure representative Intel IA32 processors with
technologies ranging from 130nm to 32nm while they execute sequential and
parallel benchmarks written in native and managed languages. During this
period, hardware and software changed substantially: (1) hardware vendors
delivered chip multiprocessors instead of uniprocessors, and independently
(2) software developers increasingly chose managed languages instead of
native languages. This quantitative data reveals the extent of some known
and previously unobserved hardware and software trends.
Two themes emerge. (I) Workload The power, performance, and energy trends of
native workloads do not approximate managed workloads. For example, (a) the
SPEC CPU2006 native benchmarks on the i7-920 and i5-670 draw significantly
less power than managed or scalable native benchmarks; and (b) managed
runtimes exploit parallelism even when running single-threaded applications.
The results recommend architects always include native and managed workloads
to design and evaluate energy efficient designs. (II) Architecture Clock
scaling, microarchitecture, simultaneous multithreading, and chip
multiprocessors each elicit a huge variety of processor power, performance,
and energy responses. This variety and the difficulty of obtaining power measurements recommends exposing on-chip power meters and when possible
structure specific power meters for cores, caches, and other structures.
Just as hardware event counters provide a quantitative grounding for
performance innovations, power meters are necessary for optimizing energy.

(http://users.cecs.anu.edu.au/~steveb/downloads/pdf/powerperf-asplos-2011.pdf)

如果他有时间,还会讲另外一个,

Title: Where to Next? Memory management in the midst of hardware and software revolutions.

Abstract:

The past ten years have delivered two significant revolutions. On one
hand, microprocessor design has been transformed by: 1) the limits of
clock reach — leading to chip multiprocessors — and 2) the limits
of Dennard scaling — leading to dark silicon and new challenges in
power management. On the other hand, managed languages and an
entirely new software landscape have emerged, profoundly affecting the
way software is sold, where it is used, and how it interacts with
hardware. Most often these changes are examined in isolation from one
another. Architects tend to grapple with the changes in
microarchitecture in the context of the familiar ground provided by
SPECCPU and meanwhile language developers tend not to confront the
consequences of microarchitectural change and where it is taking us.
In this talk I examine the state of play today, and explore the clash
of these two revolutions as they play out in the specific context of
automatic memory management, an essential element of most modern
languages whose performance is heavily dependent on the underlying
microarchitecture.

(没有打分)

Multicore 的烦恼

【编者注:这个文章是超级大学霸 David 在 IEEE SPECTURN 上写的一个描述我们整个计算机系统 big picture 的文章。 我把其中主要的论点描述一下,有兴趣懂同学直接看就是了。首先在这里需要实现说明的一个非常重要的背景就是:“Multicore 并不是我们主动选择的路,而是我们不得不选择的路!。” 非常多的人没有搞清除这个基本概念,甚至有些博士僧也没搞清除。

首先学霸老爷回顾了1975年的一场比赛,达拉斯牛仔的四分卫合着眼把球传了出去。他希望有人能接著这个球。现在的 multicore 就是 computer system 的四分卫 ( intel 等) 合着眼传出的球。为什么他们这么干,两个原因

1) power wall

2)我们still还能放更多的 transistor 放到die 上。

然后四分卫们撂挑子了,以后我们只管堆core(我只能吧球传远点,就是说我以后不动脑子了,只练力量), 你们要不要更快(try),随便。 四分卫把球传出来,能不能try 就靠我们小码农的了。如果身为码农的你写过大规模并行程序,那你应该知道这个 try 有多难!估计大部分码农 memory consistency 都还没弄明白了就被告诉必须给个100core 的 CPU写程序。苍天阿。 各种风花雪月的自动并行,自动优化研究就开始了。烧钱阿!学霸举了几个成功例子:transactions, 科学计算 和 图形图像。 为啥他们成功了?逻辑简单,没有依赖。不过即便是逻辑简单,没有依赖,要想弄个牛系统,你还得找牛程序员。

在悲观的同时,学霸还是指出了曙光:

第一点:四分卫合着眼睛传的,你们要是想try 自己去拼。我不能老是给你们传那些漂亮球了!码农们会积极主动的学习 memory consistency model.

第二点:云计算。云端的码农辛苦些。同时降低依赖,很好并行。比如同时开4个kvm在一个机器上。

除了这两点,为了证明不是岳不群, 身为学霸的 David怎么也得在危机时刻拯救世界阿,要不以后小弟们来打假怎么办。学霸深的两手都要抓,两手都要硬的 传统 中华智慧!一边开始狂优化一些 kernels. 操作系统同学们不要机动。这个不是操作系统kernel。狂优化的 操作系统 kernel 已经被首席给屠了。这个 kernel 是指的一些常用的应用和计算非常重要的基本计算方法。

那学霸的另一只手伸向哪里了呢?不要想歪了,对,是 大规模multicore design。 就是传说中的 RAMP project。 拿FPGA simulate 100 个以上的 core。

why? 两个目的:

1) 给四分卫们做做示范,挖挖散兵坑。

2)做软件的很懒的。你在 simic 上 boot 过 linux 吗? 你在 PTLsim 上跑过程序吗? 在 PTLsim 上跑个 Eclipse benchmark 要多半个星期。我们码农的宗旨就是没有硬件绝不提前开发软件。学霸把这个搞出来,好给码农们说你们Y没理由了吧,快好好干,别整天下午茶。

]

(3个打分, 平均:3.00 / 5)

陈怀临时间–浅谈网络服务处理器(NSP)

【相关文章】:

  • 《对中国系统软件的思考与建议》(PDF全文下载)
  • 对中国系统软件发展的思考与建议(四)
  • 对中国系统软件发展的思考与建议(三)
  • 对中国系统软件发展的思考与建议(二)
  • 对中国系统软件发展的思考与建议(一)
  • (4个打分, 平均:5.00 / 5)

    路由器需要多大内存?

    计算机需要多大内存?当然是越大越好了,这是用户的想法。但是计算机的设计者则必须在成本、实现难度、和取悦客户等几个因素之间进行折中,选取一个最佳平衡点。对计算机来说,其主要依据是产品的市场定位,高端商务PC至少配2G内存,低端学生机配256M就够了。如果用256M RAM的学生机来作复杂的大规模FPGA仿真,可能会发现硬盘的灯一直是亮的,这说明内存已经不够用了,操作系统正在不停的在内存和硬盘之间兑换数据,用大容量的低速硬盘来弥补内存太小的不足,但是代价是计算时间延长了很多倍。路由器是不是也向PC一样,主要依据售价来决定内存配置的大小呢?会不会也是内存越大越好呢?路由器的设计者依据哪些因素来决定内存配置的大小?一般来说,路由器的内存主要用于一下这些方面:

    (1)用于存储路由器软件指令和静态数据,路由器跟PC不同,PC是只把当前运行的程序装到RAM中,但多数路由器都是一开机就把全部程序都装到RAM中,一般来说,路由器的程序也不大(几兆到几十兆);(注:此处主要指控制平面的程序,也就是Cisco和Juniper的路由引擎)

    (2)用于存储动态数据,例如:路由表、OSPF的链路状态数据库等。假如某路由器需要支持最多10万条路由,按照每条路由256字节计算,那么大约需要200M左右内存。

    (3)用于缓冲数据报文,路由器的工作原理是存储转发。极端情况下,路由器的每个接口,至少需要缓冲一个报文,否则路由器根本不能工作。下面重点讨论这个问题。

    一般来说,路由器配置的报文缓冲区都不止一个报文。因为这样也就意味着当有新报文到达的时候,如果前面一个报文正在发送,这个报文缓冲区尚未处于空闲状态,那么新的报文势必将会被丢掉。等前面一个报文发送完了,链路处于空闲状态,但是由于刚才报文已经被丢掉了,也无法利用链路空闲状态。如果被丢掉的报文是TCP报文,那么主机势必将重传这个报文(在该路由器前面的一段线路上传输两次同样的报文),并缩小自己的发送窗口,降低了TCP连接的速率。

    也就是说,如果接口的报文缓冲区太小,将导致丢包率高,数据链路利用率低,TCP传输效率低。那么是不是报文缓冲区越大越好呢?也不是,因为报文缓冲区大到一定程度,就不能继续提高数据链路利用率和降低丢包率了。如果这台路由器处于拥塞状态,接收报文的速率远远大于接口的发送带宽,无论多大的报文缓冲区都会被填满,而报文缓冲区大了,那么也就意味着拥塞状态的时候,报文的转发延迟时间会很长。延迟时间太长的报文,对于接收方来说,已经没有意义了。以TCP连接为例,当报文大于发送方的重传时间的时候,发送方就会重传该报文,也就是说,大于TCP的重传时间的到达的报文,是没有意义的。对VoIP等应用来说,对网络延时更加敏感。

    一般来说,路由器的接口缓冲区的大小有一个经验法则(rule-of-thumb):B = C * RTT,C是链路速率,RTT是平均报文往返之间。至于这个经验法则源自哪里,我没有认真考证。但这个经验法则的主要依据是最大化TCP效率,最大化网络接口带宽利用率。如果依据这个法则来设计路由器,对中低端路由器来说,问题不大。但是对于高端路由器,是有挑战的。一般中高端Internet骨干路由器上会假设RTT为250ms,那么对于个10GE接口,需要的内存是(10G bit/s * 0.25 s) / 8 约为300MB。也许大家会说,300M不大么,但是可以预见,最近两年核心路由器的容量必将发展到单槽位80 - 160G,也就是说单大约需要2.5G - 5G内存。虽然不是完全不可实现,但还是有一定难度。从Juniper的一个白皮书(Characteristics of Switches and Routers)可以看出,Juniper也是按照这个经验法则设计的。

    但是最近的一些研究认为(sizing router buffers, Guido Appenzler, Isaac Keslassy, Nick McKeown),其实路由器不需要那么大的内存,每个端口只需要缓冲几十个报文就足够了,这样用NP或ASIC内嵌的RAM就够了,不用配置外部RAM。他主要依据是以前的经验法则是根据单TCP流来推算的,作者认为这个模型不对,实际的骨干路由器上是有很多TCP流的,因此应该按照B = C * RTT / sqrt(N)来计算,N是TCP流数量。但是另外一些研究则认为这个结论不对,路由器上不能只考虑TCP,还有很多急于UDP的语音和视频应用。反正在教授们之间,这个问题至今仍然没有一致的意见。工程师已经不再争论这个问题了,就按照B = C * RTT来设计,成本可以接受,而且也比较安全:)

    (9个打分, 平均:4.89 / 5)