为什麽都有 Windows 和 MAC 了，就是有人欠虐去碰 Linux？ 三个字 ＬＩＮＵＸ　欠改! 以上费雯 ------------------------------------------------------- 以下本文 以下是长期潜水的本猫朝发交易文的第一步(? 我不搞朝太空前进的那一套，推荐大家往地底下钻ＸＤ 本篇针对以 LINUX 作为音乐专用 "HTPC" OS 的人为目标 请斟酌自己对 OS 的理解再下手，不然当机是很正常的事情 也请神通广大的板友们多多指教 参考系统设定: 2G x 2 DDR3 ArchLinux 3.14.12-rt9 + 改来改去 如果有在追 MYAV 的 HTPC 串，会发现他们的 OS 似乎达到飞天遁地也不奇怪的境界 又听说他们将两个 DDR3 分开，一条放系统 一条放音乐档的时候，我就开始手痒了... 个人的猜想是 他们隔离了一块 OS 的记忆体管理不能操作的物理位址 并且将音乐档用 巫术 存到那一块被孤立的记忆体区段处来做拨放 同时还要确保音乐档的记忆体区段是 "物理地址连续" 的状态 (关於 OS 的虚拟记忆体位址和物理记忆体位址的关系，可以查一下资料 重点是连续虚拟位址并不等於连续物理位址，而普通程式只能看到虚拟地址) 这就有点类似 Jplay 将音乐存进连续物理记忆体做拨放 只是与 OS 上乱七八糟的东西做了更进一步的隔离 而 LINUX 能不能做到呢? 答案当然是: MANUAL 纯手工 纯天然..... LINUX: 想要玩我? 我把原始码 开发员论坛 API 都放在那边了 去爆肝吧XD 废话少说，以下是我花了三天整理出的一种实现方法 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 第一步 隔离两条 RAM 的物理地址 把两条 RAM 改成两个单通道，因为双通道的原理就是让两条 RAM 同时进行存取 这样可以加倍频宽，但是物理地址会分布在两条 RAM 上面 改成单通道之後，两条 RAM 的物理地址则会在中间分成两半 什麽? 效能变差? 就网路上的评测数据来看 单双通道的效能之间还是有一定落差 毕竟有两个记忆体主控可以用 偏偏只用一个根本是讨打www 但是音乐档案的传输相较来说算是十分缓慢 这个速度差应该是可以忽略 但是如果对这一点速度斤斤计较 这一步是可以忽略的 不会影响以下的步骤 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 第二步 限制 OS 的记忆体管理范围 这需要更改 kernel boot parameter(启动参数?) 以 GRUB2 和 2G x 2 RAM 为例: 加上 memmap=0x80000000 就可以将 OS 管理的记忆体 限制在物理记忆体 0x0(0G) ~ 0x80000000(2G) 之内 更进一步也可以加上 memmap=0x80000000\$0x80000000 (\$ 等於 $，为了防止 GRUB 误读) 让 0x80000000(2G) 位址以上 0x80000000(2G) 大小的记忆体设定为不能存取 这两行可以加进 /etc/default/grub 里面，如 GRUB_LINUX_CMDLINE_DEFAULT="memmap=0x80000000 memmap=0x80000000\$0x80000000" 然後更新 GRUB (更新的指令因系统而异)，重开机 "理论上"你的 OS 可用记忆体就会被砍半了 那麽 你就有满满的 2G 记忆体可以乱搞了吗? 答案当然是 NO，不只有 OS 会想搞你的记忆体，连 BIOS 也会来参一咖 要知道你有多少记忆体是没被 OS 和 BIOS 玷污过的处女地， 运行 dmesg 查看系统日志，你会在开头附近找到 [ +0.000000] e820: BIOS-provided physical RAM map: [ +0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009d7ff] usable [ +0.000000] BIOS-e820: [mem 0x000000000009d800-0x000000000009ffff] reserved [ +0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved [ +0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000c9796fff] usable [ +0.000000] BIOS-e820: [mem 0x00000000c9797000-0x00000000c979dfff] ACPI NVS [ +0.000000] BIOS-e820: [mem 0x00000000c979e000-0x00000000c9bedfff] usable [ +0.000000] BIOS-e820: [mem 0x00000000c9bee000-0x00000000ca049fff] reserved [ +0.000000] BIOS-e820: [mem 0x00000000ca04a000-0x00000000dd731fff] usable [ +0.000000] BIOS-e820: [mem 0x00000000dd732000-0x00000000dd93afff] reserved [ +0.000000] BIOS-e820: [mem 0x00000000dd93b000-0x00000000dd953fff] ACPI data [ +0.000000] BIOS-e820: [mem 0x00000000dd954000-0x00000000dde8bfff] ACPI NVS [ +0.000000] BIOS-e820: [mem 0x00000000dde8c000-0x00000000deffefff] reserved [ +0.000000] BIOS-e820: [mem 0x00000000defff000-0x00000000deffffff] usable [ +0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved [ +0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved [ +0.000000] BIOS-e820: [mem 0x00000000fed00000-0x00000000fed03fff] reserved [ +0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved [ +0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved [ +0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved 和 [ +0.000000] e820: remove [mem 0x80000000-0xfffffffffffffffe] usable 以及 [ +0.000000] e820: user-defined physical RAM map: [ +0.000000] user: [mem 0x0000000000000000-0x000000000009d7ff] usable [ +0.000000] user: [mem 0x000000000009d800-0x000000000009ffff] reserved [ +0.000000] user: [mem 0x00000000000e0000-0x00000000000fffff] reserved [ +0.000000] user: [mem 0x0000000000100000-0x000000007fffffff] usable [ +0.000000] user: [mem 0x0000000080000000-0x00000000c9796fff] reserved [ +0.000000] user: [mem 0x00000000c9797000-0x00000000c979dfff] ACPI NVS [ +0.000000] user: [mem 0x00000000c979e000-0x00000000daf7ffff] reserved [ +0.000000] user: [mem 0x00000000dd732000-0x00000000dd93afff] reserved [ +0.000000] user: [mem 0x00000000dd93b000-0x00000000dd953fff] ACPI data [ +0.000000] user: [mem 0x00000000dd954000-0x00000000dde8bfff] ACPI NVS [ +0.000000] user: [mem 0x00000000dde8c000-0x00000000deffefff] reserved [ +0.000000] user: [mem 0x00000000f8000000-0x00000000fbffffff] reserved [ +0.000000] user: [mem 0x00000000fec00000-0x00000000fec00fff] reserved [ +0.000000] user: [mem 0x00000000fed00000-0x00000000fed03fff] reserved [ +0.000000] user: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved [ +0.000000] user: [mem 0x00000000fee00000-0x00000000fee00fff] reserved [ +0.000000] user: [mem 0x00000000ff000000-0x00000000ffffffff] reserved 第二个表是加上限制之後的开机物理记忆体使用表 其中包含 OS 和 BIOS 保留的记忆体区块，因为这些保留区大都很小，所以 在 0x80000000-0xffffffff 之间的值找到几块较大的记忆体区段 user: [mem 0x0000000080000000-0x00000000c9796fff] reserved (约1.1G) user: [mem 0x00000000c979e000-0x00000000daf7ffff] reserved (懒得算) 这几块就是你可以随便恶搞的记忆体范围了! (不代表 reserve 的地方就可以乱动，因为那里是妖魔鬼怪常常出现的地方) 当然 开机之後还是会动态的更改可用的记忆体范围 所以还要再参考 /proc/iomem 的值确认目前真正可用的范围 (都看的到这里了 我相信你一定看得懂 XD) # 如果选错范围，之後极有可能覆写系统的设定以及数据，到时候电脑就死给你看惹 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 第三步 让留下来的物理记忆体可用 之前说过 这些被隔离下来的物理位址并不被 OS 所管理 代表的是 OS 的虚拟位址址空间不会包含这些物理位址 而 OS 上普通的程式只能操作虚拟地址覆盖之下的的记忆体 因此 我们就需要将隔离下来的物理记忆体映射到虚拟记忆体 以便程式存取 我所采取的方式是 建立一个模组(module)管理可用的记忆体范围 这样 程式只需要使用这个模组分配的记忆体 就不需要管那些 OS 和 BIOS 的鸟范围 重点来惹 LINUX 之下所有模组由於运行在系统空间 (普通程式运行在用户空间 限制多多) 就可以直接存取物理记忆体 而且使用的物理位址能够 保证连续! 保证连续! 保证连续! 这是非常重要 而且十分合乎广大烧友(? 需求的性质 又 如何将物理位址映射到用户空间给程序使用呢? 就是 LINUX 的 API 发挥用场的时候了 remap_pfn_range( ) 这个函数能够在 "系统空间" 将物理地址映射至 "用户空间" 也就是说让物理地址能够包含进虚拟地址中 同时虚拟地址及物理地址是 1:1 连续对应 非常的赞 mmap( ) 这个函数能够在 "用户空间" 呼叫 "系统空间" 中的上面那一个函式 取得直接对应至物理地址的虚拟地址 这两个函式是这个方法能够成功的关键 不罗嗦 以下是模组的原始码! http://www.fileswap.com/dl/pBoxVnfBRd/ 免空过期可以跟我站内信要 里面包含模组的原始码 测试程式 以及mpd的patch 如果在使用它发生了任何问题 本猫概不负责 请谨慎服用XD --------------记得修改模组的原始码再编译 插入模组--------------- mmapdrv.c: (里面的 MODULE_LICENSE("GPL") 中的 "GPL" 是不能改的 改了这个模组就坏了(认真 o'_'o) 其他地方随你搞 XD) TRUNK_ADDR 是每一块物理位址的首位址 TRUNK_SIZE 则是每一块记忆体区块分配的大小 里面可以填入自己在步骤二找到的闲置物理位址 在这个模组的预设参数下 我分成 0x80000000 - 0x9fffffff (512M) 0xa0000000 - 0xafffffff (256M) 0xb0000000 - 0xbfffffff (同上) 0xc0000000 - 0xc8ffffff (更小) 0xca000000 - 0xd1ffffff (再小) 0xd2000000 - 0xd9ffffff (同上) 这些值每个人 每台机器都不同 记得一定要修改 如果区块数量上有变更 修改 #define TRUNK_NUM 至相同的数量 当外部程式呼叫这个模组分配记忆体时 这个模组会将合乎程式需求大小的 最小记忆体区块分配给程式 并设定这个区块为已使用 直到程式释放这块区域 大家可以看到 每个位址都是连续且对其分页的大小 而且对他写入资料之後 关闭记忆体再重新开启 记忆体里面的值还会维持原样喔XD 因此这些地方适合放入一整个档案 超大的buffer 或是塞的下的所有猥亵物(? # 懒得修的bug: 一个程式不能同时开两块记忆体 否则在释放记忆体时 会只释放其中一块 test.c 这是测试程式的原始码 他会跟模组要一块512M大的连续记忆体 (可改) 在里面写入 1 2 3 ..... 等等 写完再从头读出来 -------------------------------------------------------------------- 只要打 make 就会帮你编译出模组以及测试程式 还会将模组插入 OS 中 然後输入 mknod /dev/mmap_dev c 400 0 建立与这个模组沟通的介面就大功告成拉 之後执行 ./test 等他跑完应该就可以确认模组到底能不能用了 如果执行程式有任何问题 跑出来的错误讯息应该很好 debug 在 dmesg 拉到最後也会有模组执行到各个阶段的提示 如果有试着尝试这个模组的人 祝你好运 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 第四步 实作 在我的原始码包里面还有一个叫做 HugeAllocator.cxx.patch 的家伙 HugeAllocator 是 mpd 创造放置已经解码完毕的音讯档的空间的函数 可以发现 mpd 其实也是用 mmap() 这个函式打开记忆体 只是它是用 OS 的管理空间中的记忆体 这个补丁可以把它要记忆体的地方改成这个模组提供的记忆体区块 在 mpd 的原始码打补丁之後重新编译安装 (自己google~) (因为 mpd 的源码更新有够快 如果补丁不合用了请依照逻辑自己做补丁..) 现在.... 把 mpd.conf 中的 audio_buffer_size 改到 130000 吧!! (大约128M) 这样 在播音乐的同时mpd会努力的解码 "整首" 音乐档 解码完的结果会塞进 记忆体中 这样除了前面几秒的衰声期(我是听不出来拉..)mpd 会去读取硬碟里的 档案 结束之後所有解码後的东西会放入 "物理位址连续" "没有其他人干扰" 的地方 而不用像一些程式把未解码的档案塞进记忆体 然後边解码边播音乐...... 这个模组用途多多 就看你能不能发挥它的功能 另外 如果不合你的使用 就自己修改原始码吧 不要找我 (逃 但是希望用了可以回馈一些感想给我 当作鼓励吧 至於 问我改了这个补丁到底有没有差? 我只能说 自己改的东西听得最爽XD ------------------------------------------------------------------------ 感谢所有没有End的版友的耐心 看本猫班门弄斧一般 至於End的版友们 如果是因为没有接触过 HTPC 推荐去源音音响听听那里的系统 如果是因为觉得本猫太弱 欢迎拍打喂食(X 用力鞭我(V 希望本篇可以减少大家摸索优化方法的时间 下一篇天晓得生不生的出来w 以上! --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 114.41.27.119 ※ 文章网址: http://webptt.com/cn.aspx?n=bbs/Headphone/M.1408822440.A.09B.html ※ 编辑: selnec (114.41.27.119), 08/24/2014 04:00:52 所以我推荐无显卡的 headless 系统 (? ※ 编辑: selnec (114.41.27.119), 08/24/2014 09:20:08 有没有差可能要看系统等级 不过物理地址连续很流行阿 不觉得跟别人说 "我的RAM真的他X的超连续" 很潮吗ww ※ 编辑: selnec (114.41.27.119), 08/24/2014 10:13:04 事实上是 这东西我星期五早上在宿舍搞完就回去了 还没有认真测过差别XD 也不打算太认真比较 我觉得改机的乐趣比较大Orz ※ 编辑: selnec (114.41.27.119), 08/24/2014 15:37:31 原PO是只猫 会恶搞电脑也是一件很正常的事情 ※ 编辑: selnec (36.228.227.74), 08/25/2014 00:19:13