為什麼都有 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/m.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