qyb的博客

Fedora11 on HP2230s

qyb 发表于 2009-06-11 01:00:17

公司新发的小本，正好配最新的distribution.

  • 最重要的，wifi工作正常，NetworkManager 里简单配置一下就可以通过公司的 LEAP 认证。这里附带说一下，我是从 F11-Snapshot 安装来的，最开始无线驱动不起来，报什么"Kill switch must be turned off for wireless networking to work"，后来系统yum update了一下后就能用了
  • 图形驱动也很好，配置上了 Solar 的开机启动效果。算是过了一把 KMS + Plymouth 的瘾。再附带说一下，开源图形驱动的支持方面，Intel > ATI > Nvidia
  • 支持面板上的音量滑动调整，但不支持音量的on/off按键
  • 屏幕亮度调整也支持
  • 外接投影只能用桌面扩展，无法clone，我猜测是屏幕分辨率和投影分辨率不一致的原因。不过我觉得扩展也挺好，这样可以一边投影一边看事先准备的演示提示，哈。
  • 因为是第一次在小屏幕上用Gnome，这才注意到它的字号是根据磅数来的——就是说自动使用更大的像素值，确保在不同的设备上看到的字的物理大小是一样的。这一点比windows要人性化
  • Linux下似乎比Windows下要耗电一些
  • 偶把缺省的宋体换成了文泉驿，官方源里就有
  • GNOME对蓝牙的支持也不错，比 XP 强
  • 传说F11对指纹识别集成得很好了，但2230s上的设备AES2810尚不被支持

    • 才用了差不多一个星期，以后慢慢折腾这个系统吧。现在我的工作模式是笔记本用 Linux，台式机上跑 XP，outlook/office/IE/MSN 啥的都在台式机上用，然后开一个 rdesktop...是不是太装了点？

    Topic: 技术

    中关村四小印象

    qyb 发表于 2009-06-10 23:47:29

    今天带达达去中关村四小面试。除了小孩要面试外，家长也得面试。按照学校的要求，还带了俺们的学历学位证明，面试的老师很仔细的一一验看。小朋友的面试不知道具体如何，就是在外面看着她被要求跳了会绳，还真算是全面考察了。

    印象深刻的是两点：
    1. 硬件条件看起来不错。

    2. 图书馆对面的展板上推荐四五六年级的阅读书里有《动物庄园》，另一边墙上则贴着十来个小孩写的少先队入队心得之类的东西。。。。哦哦哦，对比强烈啊

    Topic: 社会

    Gears 加入了 Drag & Drop 的功能

    qyb 发表于 2009-06-08 18:12:06

    这个 Drag&Drop 是指从桌面环境中拖入文件到浏览器，0.5.21 版本中带了这个功能. 随着 0.5.21 一起发布的，还有另外两个新增的 API

    印象中这是第一次 Gears 在 0.x.y 的 y 发布中，升级了新的 API，0.5 的首次发布的 ChangeLog 见 这里

    另外很有意思的一点是，Gears 给其它浏览器制作的扩展都自动更新了，但... Chrome 反而还停留在 0.5.19，一点都不 Teamwork，哈哈

    Topic: 技术

    09搜超联赛第一场

    qyb 发表于 2009-06-02 23:18:21

    2:3 输给了 go2map

    作为中卫打满全场，基本上没有给对手从我这里正面突破的机会，就是最后一个失球和门将没配合好

    从场面上看，这个比分还算合理，我们完全是依靠板凳的厚度在下半场趁对方体力出现问题打进了两个球

    go2map 和两年前比起来主力比较固定，我们还在磨合，期望下场能更好

    Topic: 生活

    关于 cgroup (control group)

    qyb 发表于 2009-06-01 20:56:15

    I/O controller 这篇文章提到了 control group，看起来它是 Linux 内核中一个比较重要的概念，于是去找了找资料，给自个科普科普

    最早 control group 是叫做 "Containers" (06年9月)，利用 configfs 作配置.

    "Containers" 着眼于资源的分配，有两个重要概念：
    1. subsystem, 内核可以给进程提供的服务/资源

    2. container, 一个进程组，成员共享同样的一个或多个子系统分配限制。containers 是层次的，一个 container 可以 hold 多个 container

    它的最可取之处是创建了一个资源分配的框架，其它开发者可以利用这个框架去开发自己的资源分配patch，比如上回提到的磁盘设备。

    后来不知道为什么没有采用 configfs，自己搞了一个 container filesystem.

    最后在 2.6.24 内核(08年1月)中被正式合并进入主线，被改名为 control group 或简写为 cgroup. 详细介绍在 内核源代码文档目录中的cgroups.txt 。

    刚刚进入 2.6.24 的时候，只有 cpusets(绑定cpu/memory node) 和 CFS group scheduling( cpu 带宽分配) 两个资源。2.6.25 又引入了 memory resource.

    去搜索一下 cgroup，可以看到有好多有意思的 patch，比如 per cgroup 的 OOM killer，甚至 swap cgroup 等等.

    Topic: 技术

    Which I/O controller is the fairest of them all?

    qyb 发表于 2009-05-28 21:39:33

    简单翻译：http://lwn.net/Articles/332839/

    I/O controller 用来调度对存储设备的访问——根据系统管理员的配置，对不同类型的进程指定不同级别的访问策略。它可以避免I/O密集型的访问不合理的占用资源，显然，对于那些运行很多个虚拟机的系统，这个非常有用的特性。但是，现在Linux的主线版本，还没有加入I/O controller.

    看这么一张图，是磁盘I/O的过程

    首先是请求Virtual block，是设备映射层，比如 MD RAID Layer，把请求映射到真正的物理设备；但在实际请求物理设备之前还要通过 I/O scheduler，它应用某种策略以提高磁盘访问效率，尽量避免来回的seek；最后才是硬件访问.

    I/O controller可以在block layer里面（上面这个蓝框）的任意一层实现

    【具体技术实现细节就不翻译了】
    1. dm-ioband ，在Virtual Block Layer 实现。这里有两个问题，一个是没有用现成的control group 机制；另外就是它的控制是基于进程的，而对于内核的I/O，比如VM管理，它没有对应的策略。于是原作者又弄了一个 blkio-cgroup patch，解决了这两个问题。

    它的缺点在于，a. 必须要使用设备映射, b. 对底层的I/O scheduler有影响, c. 没有提供任何 QoS 保证，只是做固定的I/O带宽比例分配

    2. io-throttle , 它利用了control group，这样策略参数可以通过 cgroup filesystem来配置。

    它的配置模式中，每个cgroup只能联系一个设备，一方面多个设备就必须配置多个group，但另一方面对不同的设备可以配置不同的策略。

    一个最有意思的设计是它在I/O请求初始化的地方实现，包括内存管理子系统、文件系统、异步I/O的writeback、块设备处理...这样控制带宽的方法之一是让进程去sleep一段时间，看起来这样做比维护一个块IO队列要强。

    io-throttle 的好处在于代码相对来说比较简单，可以通过让进程睡眠的方法来控制流量；它没有真正的 QoS，但在某种程度上有点接近。它的问题在代码侵入性是最强的，涉及的子系统太多，另外它同样会影响I/O scheduler策略

    3. io-controller , 解决了上述两个方案共同的缺点——它在 I/O scheduler那里实现了一个基于cgroup的I/O controller。虽然支持所有的主线 scheduler：CFQ、Deadline、Anticipatory、no-op，但看起来好像主要是针对 CFG 做的优化。

    它弥补了前两个 patch 的缺点，但它不能针对不同的设备配置策略（这是io-throttel的优点），而且并不是在所有 scheduler 下都可靠工作。

    Linux 不太可能引入多个 controller，那它最终会选择哪一个？ 目前看 io-controller 最受青睐，但相信其它两个方案也会继续改进直到最后幸运者胜出

    Topic: 技术

    SMPlayer 确实不错

    qyb 发表于 2009-05-27 21:02:40

    说说两个很少提到的优点
    1. 首先是得益于 ffmpeg 对 RV30/RV40 的支持，无须额外的解码器就能看 rmvb 了。

    2. 其次是 SMPlayer 支持播放 DVD iso 文件，这样就免去了用虚拟光驱额外转换的步骤

    我觉得以后不会再考虑 MPC + ffdshow 这样的组合了

    Topic: 技术

    译：4K disk sectors

    qyb 发表于 2009-05-27 08:23:44

    简单翻译下 http://lwn.net/Articles/322777/

    自从 1956 年问世以来，40余年间硬盘变化甚大，但堪称奇迹的是，每物理扇区512字节的规范，一直保留到现在

    如今设备商已经计划升级这个规范，生产每扇区 4096 字节的硬盘... why?

    因为从电子比特转换到磁比特的过程中，不可避免会发生些错误，术语叫 Signal to Noise Ratio (SNR)。于是在物理设备上对应每个扇区，会尾随一块 ECC 校验区域，见下.

    随着磁密度的越来越高，ECC 的需求也越来越大。例：在 215 kbpi(KB每平方英寸)，512字节扇区需要24字节的ECC，到了 750 kbpi 的时候，每扇区就需要40字节的ECC来保证同样的可靠性了。但如果改为4096字节的扇区，只需要100字节ECC就可以...

    总之，加大sector是有很大成本好处的。那么设备商们打算怎么推进这个事情呢？

    在软件（其实就是操作系统啦）还没有准备好的情况下，硬件制造商会推出 read-modify write(RMW) 技术的 4k 扇区来仿真 512 字节扇区。简单说就是对外的接口看是512字节，读接口仿真比较简单，写一个扇区就是传512字节数据进去，磁盘自己把整个4k的内容都读出来，覆盖对应的512字节数据，然后再写回。。。这种设备在 2011 年将推向市场

    （qyb注：考虑到缺省文件系统就是4k分块的话，如果操作系统对这类设备优化得当，性能是反而可以提高滴——因为ECC对比是变少了）

    再过若干年主流操作系统都对 4k 扇区优化好了，软硬件就和谐了

    Topic: 技术

    评：Scaling Memcached: 500,000+ Operations/Second with a Single-Socket UltraSPARC T2

    qyb 发表于 2009-05-25 17:59:45

    见： http://blogs.sun.com/zoran/entry/scaling_memcached_500_000_ops

    以及顺道去传说开发 scalability patch 的 Trond Norbye blog 看了看，感觉如下

    1. SUN 在硬件上是有独到之处的，比如这个 UltraSparc T2 在一颗芯片上做到了 8 核，每核 8 进程——传说 Intel Nehalem 计划开发每核 4 线程的，不过到现在好像还只是每核 2 线程。注意 Intel 的超线程是 SMT 技术（准确的说 hyperthread 只不过是一个技术推广出来的商标而已），UltraSparc 是 CMT，原理有所不同

    2. scalability patch 没有在其 blog 和邮件列表上找到，估计应该已经集成到 memcached 1.3.2 里面。。。现在最新版本是 1.3.3，我觉得需要高性能 memcached 的除了 facebook 的版本外，这个 1.3.x beta 也值得考虑

    3. Trond 给 memcached 增加了一个引擎接口（ http://blogs.sun.com/trond/entry/memcached_and_customized_storage_engines ），貌似以后开发 memcachedb 啥的只需要把 storage_engine 改成 BDB 或者 Tokyo Cabinet 就成了.

    4. 从程序开发调试的角度来说，OpenSolaris 有优势，SUN 在高性能计算方面的积累确实很强。C/C++ 程序员可以考虑是否用它来作工作环境（然后再用 VirtualBox 装个 Linux，哈）。

    Topic: 技术
    订阅 RSS - qyb的博客