前几天在 LinuxFab 上的 [QA 特搜] 看到打开 DMA 的方法，迫不及待拿来一试，首先下指令 :
hdparm -Tt /dev/hda
测测目前的速度， 同样指令多跑几次求一个平均值, 然后用 :
hdparm -d 1 /dev/hda
把 DMA 功能打开，再测一次速度，哇 ! 果然就是不一样，Timing Buffer disk reads 的效率足足提升了四倍以上 !
当然测试的数据不是拿来看爽的，真正跑程序的时候要有效果才算数， ㄟ.....说真的，开了DMA之后，照往常的习惯打开 Xwindow，开个 Netscape 来上网，都还是要读个一阵子，好象没有感觉快多少勒 ? 干脆拿个表来计时好了，结果果然令人失望，开不开 DMA，结果都一样。
啊....怎么会这样，好吧，干脆拿出特耗硬盘的指令 locate -u 好好的给它操一下，这下总该看的出差距了吧，嗯.....没开 DMA 花了1分22秒，为避免有些资料 cache 在 RAM 里面影响测试结果，重开机打开 DMA 再跑一次，嗯.....1 分 22 秒，天啊，又是同灯同分 !
难道 DMA 是没用的吗 ? 还是 hdparm 根本没用还秀个假数据来骗人 ? 怎么会这样 ? 嗯.....还好以前上课没打瞌睡，对 DMA 这东西还稍有概念，在这里跟大家解释一下。
硬盘上的东西，一定要先搬到RAM里面才能拿来执行，早期把资料由 Hard Disk 搬到 RAM 的工作，是由 CPU 来执行的，而这项工作可不如想象中的轻松，资料是以 1 byte 为单位来搬的，所以要读取 1 MB的资料，CPU要从硬盘搬 1 byte 到 CPU的缓存器，然后再从 CPU 搬到 RAM，重复这样单调而无聊的动作 1048576 次。
杀鸡焉用牛刀，以一个高价位而且多用途的 CPU 来做这样的苦工，实在有点可惜，于是 DMA(direct-memory-access) controller 便诞生了，CPU 只要告诉它 "请帮我搬 1MB的资料到内存" ，DMA controller 就会开始做这份苦工，同时间 CPU 便可以去做别的工作，等到资料搬好，DMA controller 会通知 CPU，CPU 就有现成的资料可以用了。
了解 DMA 的运作原理，就不难想象为什么之前的测试结果都相同。因为处理 locate 这一件简单的事，对 CPU 来说是游刃有余的，没有 DMA 做帮手，照样处理的很妥当。所以呢，当你需要从硬盘存取大笔的资料，同时间 CPU loading 又重的时候，DMA 的价值就会显现出来。
重新设计测试的方式，要 loading 重而且存取又多的，就属压 mp3 这件事了，于是抓了 NotLame 来，针对一个 53.8 MB 的 wav 档做压缩，嗯.....没有 DMA 花了 1 分 52 秒，重开机打开 DMA 再试一次，哈哈 ! 1 分 37 秒，果然有比较快。
以目前的硬盘跟主机板来说，很少没有支持 DMA 的，打开 DMA，多多少少都会增进你的效能，尤其在 High Loading 的时候特别显出价值，不要犹豫了，打开你的 DMA 吧!
摘自：
hdparm -c 1 /dev/hda
使用32bit模式;
hdparm -X34 /dev/hda
用DMA33
hdparm -X66 /dev/hda
用DMA66
其他的设置,大家有兴趣,我可以考虑写一篇专文
文章来源于领测软件测试网 https://www.ltesting.net/
