Tilera fos 分布式操作系统实现
- 2. FOS1学习 –FOS的由来FOS的背景Factored operating system (FOS) ,一种基于分布式计算思想的操作系统设计实现 （更早的1980年，在荷兰教书的美国人Andrew S.Tanenbaum老先生就已经提出理论和实现）。
- 3. MIT 计算科学和人工智能实验室 的 两位教授 Jason Miller 和Anantagarwal（后者同时也是tilera的CTO）在其论文“an operating system for multicore and clouds: mechanisms and implementation”中提出FOS。
- 6. A.Tanebaum是这方面的世外高人（风清扬？），远在PC机的功能不足以强大到作为多用户系统的90年代，他就开发了以教学为目的的Minix，以及后来的Amobea OS,均是基于Microkernel 和Message的分布式设计, ACM 和IEEE成员。Andrew S.Tanenbaum， CS学界泰斗，1944年生人，Minix的开发者，算是为Linus.Torvalds开蒙的人吧(他俩当年还为Minix和linux(或者说分布式OS和单一全功能OS)的优劣进行过辩论，最后发展到大打嘴仗，甚至牵扯到ken thompson和david miller,那是90年代的事情了)，我在读他这本书，当然。。。他的书每本都是圣经。9/30/2010
- 8. Namespace (API 内部的LB，程序员透明)
- 10. Messages 基于消息
- 12. FOS server 设计原则：Time multiplex vs space multiplex （通常SMP系统，任务调度器在一个物理机上的不同的core间进行任务（进程）调度，分配的资源是CPU的time slice ； 与这对照的，FOS是在name service 中进行调度，调度的资源是spatially-distributed 的多个core上运行的OS SERVICE）OS factor as function-specific services（系统服务按照分布式，并行的原则实现 。应用通过libfos，以消息的方式去申请资源 。我的理解： 通常OS 实现的资源管理，以系统常规调用去激活例程（routine）; 而在FOS中间，文件访问，内存申请等等均是通过service 来实现）OS adaptor resource utilizing （服务的利用率是被衡量的，OS 在分布式的环境中间）Fault avoid （spawn to build a fleet and recycle）： OS 会探测到故障并据此进行相应的调度。9/30/2010
- 13. FOS1学习 –micro kernel微内核：我们熟悉的内核(kernel)与用户空间(user space)对应，抽象用户程序对具体计算机资源的访问和管理,当然还有其他细节（并发多用户环境下）； 这些资源包括但不限于{物理内存，硬盘上的文件，网络栈，中断，其他IO设备。。。。}
- 15. OS 和kernel的关系，在我们熟悉的情况下是1:1 ； 而在FOS下，是1:X (tilera目前是64~128，明年是1024吗？)
- 16. 微内核的组成：Protected message layer Name cache for performance purpose基本的时间片复用管理 (一个core 仍然可能运行多个线程，例如一个FileSystemrequest 和由自己申请的FS call)API （仅仅实现内存地址空间申请和线程的创建，特别是其设计为可以以一种异地内存访问的形式工作，例如：运行在core-A上的进程可以对core-B上异地内存的进行修改操作（原文为Modify）。。。Maybe Numa？）9/30/2010
- 17. FOS1学习 –messages (消息层实现)消息层实现：消息是为了实现进程间的通讯，在更加一般化的讨论下，如果如果不区分相互通信的进程是本地的还是异地的，那么就是FOS希望达到的目的，因而FOS实现了一个简单的messagesAPI来达到这一目的 ，而这样有两个最主要的好处：超越了通常多核环境下对于共享内存的两难要求，而这是MPI或者目前多核结构下难以完美解决的问题。。。可以参考MESH协议和INTEL 最新的QPI结构来了解该领域最新的进展。既然不要求共享内存，那么就可以做到跨硬件体系结构来实现消息传递。 我们可以设想在AMD和INTEL平台间，甚至是在X86和MIPS之间进行进程间的消息传递 （tilea和mips一脉相承）数据的共享变得更加明确而不用担心冲突，因此程序员能够更加小心的考虑相互通信进程间的大量共享数据、、、、说实在的，由于论文公布的资料有限，没太理解该句表述。。?消息层的实现达到如下的这样一些目的：抽象了对于不同系统服务层的调用过程，进程不用关心要通信的对方实在本地还是异地，而这在传统的UNIX实现上是以IPC，共享内存，信号量，（本地）和网络SOCKET来区分的； 也即是说，在传统环境下，进程间通信和网络间通信将依赖于不同的编程方法。。。那么？？（更加一般化的讨论，似乎可以将通信分为intra-machine和inter-machine , 后者的一个现实的例子: 比如你去google一个key word ..? 具体的实现上：首先： FOS的messages API 对应用程序封装了上述内容，但是在内部，以share memory来进行本地通信； 以proxy server 进行异地通信，如下所示再者：每个进程具备一组mailbox以接受其他进程的消息， 而mailbox在创建的时候将由一些可供其他进程寻找的key来标识自己。 （和naming有关乎？？？?）9/30/2010
- 18. FOS1学习 –Naming (命名空间实现)命名空间的实现：具备一个命名服务器，其管理着不同翱厂服务的统一命名空间（蹿颈濒别蝉测蝉迟别尘服务，网络服务）
- 21. 所谓的名字具备URI的形式，这样的抽象化带来的好处是灵活性和进行LB时候的本地化局部亲和性。。。（）论文中也谈到，命名空间还有这样一些需要完善的地方，如：进行调度的策略（目前有RR, core的亲和性，队列长度）和所有其他一些命名服务（GFS name, HDFS…）相似的，naming service 需要解决的是在提供名称服务时既能够保证低延迟又能保证一致性。例如，如果某个提供service 的core需要离开或者加入的时候去保证namespace的update。论文认为目前在P2P应用中间应用广泛的DHT（分布式哈希表）应该能够成为一个好的解决办法。（听起来时候再FOS上暂时没有这么实现）。西贝流士按：这样设计的好处是，某个core offline的几率要比SMP结构下共享cache 条 dirty的几率小，所以效果要好使应该的，而且，DHT也已经被证明其简单和高效了西贝流士按：具体的细节论文中间没有再详述，我们不妨可以想象：基于文件服务的命名也许是这样： nameURI.Filesystem.ext3.server001.core001./var/log/DEMOlog -- 标识了一个运行在machine001上第001core上的一个命名服务进程，而如果name server 觉得这台服务器lwork load 不高的话，应该就会优先将该请求进程申请的文件调用仍然放回到本地服务器上去，从而满足本地亲和性的原则。9/30/2010
- 22. FOS1学习 –OS Services (操作系统服务的实现)系统服务的实现：和云计算环境下面临挑战一样的，多核计算环境也需要提供按需求进行计算能力扩展的特性
- 23. FOS 将通常的OS service 抽象为由一组运行在不同machine上的进程组成（称为Fleet），这些进程是位置上分布的（spatially-distrbuted）， 但却是通过之前提到的messages 进行协作。
- 25. 这样的fleet 例如file system fleet, naming fleet, scheduleing fleet, paging fleet, process management fleet…etc ; fleet 提供了一种形式上优美的方式来实现扩展性和柔性的目标，但是缺点是，对于串行（straight-line ）的编程模型来说却有些复杂的；而且，不同类型的OS 服务显然需要满足不同的并行化策略和规范，FOS通过以下的思路来面对该问题：合作的多线程编程模型易用的RPC和序列化规则（facility）在数据结构上，基于数据共享原则的通用样式（ data structure for common patterns of data sharing），原文没有再进一步的没再详述了，如果能拿到TILERA的SDK就知道了? OS service 的服务器模型：该模型设计的思路是： 抽象出与物理服务器无关的调用来维持一个逻辑的本地库；并且对于coder而言，消除并行编程的复杂性。其他特点包括：基于事件驱动的模型，而事件就是我们之前提到的message 包含的内容
- 27. 右图呈现了mBOX的设计，而且显然是以非阻塞方式处理External mailbox （新进request）Internal mailbox (处理fleet内部的messages)Response mailbox （处理pending的request) 西贝流士：在人们已经熟悉了epoll/libevent/libV等事件通知模型以后，OS service server就可以理解为类似的实现，这已经被公认为高效而成熟的网络服务器并发模型了。9/30/2010
- 28. FOS1学习 -12010 12-27形象的描绘了一个典型的系统调用或者函数请求的过程，注意其中的几个角色： FOS server; proxy server, libc和其下层的libfos,唯一不清楚的是hypervisor的角色，在microkernel 之下？ 论文中没有提到！
- 29. FOS2 -1 多核计算环境 基于消息和OS 服务模型的分布式一个physical layout ,挺好玩的?9/30/2010
- 30. FOS2-2 满足POSIX 兼容？的fs调用过程How to compliance with POSIX,其实太具体了，如果有，其实就是直接读代码。。9/30/2010
- 31. FOS2 -3OS service server提供服务的过程制作者：西贝流士Sibeliuscn@gmail.com 注意3个mailbox 队列External mailbox （新进request）Internal mailbox (处理fleet内部的messages)Response mailbox （处理pending的request) 9/30/2010