DPDK网卡绑定与解绑：从内核移交到用户直控的完整实践

1. 项目概述为什么网卡绑定与解绑是DPDK应用落地的第一道门槛DPDK——Data Plane Development Kit这个在高性能网络领域几乎无人不晓的开源框架它的核心价值从来不是“跑得快”而是“把控制权真正交还给应用层”。而实现这一点最基础、最关键的一步就是让网卡彻底脱离内核协议栈的管辖。你不能一边让Linux内核还在偷偷收发ARP包、处理TCP重传、维护netdev状态一边又指望DPDK应用以微秒级延迟直通硬件——这就像让两个人同时握着方向盘开车不出事故才怪。所以“1.2 → DPDK 的网卡绑定、解绑过程解析”这个标题看似只是讲两个命令dpdk-devbind.py的-b和-u实则是一把钥匙一把打开整个DPDK世界大门的物理钥匙。它解决的不是一个“能不能用”的问题而是一个“能不能稳、能不能查、能不能扩”的工程性命题。我带过的几个团队在第一次部署DPDK转发程序时80%以上的现场故障都卡在这一步网卡没绑对、驱动加载失败、PCI地址写错、甚至绑完之后系统SSH直接断连——这些都不是代码bug而是对绑定机制理解不深导致的“地基塌陷”。本文不讲抽象原理只讲你明天就要上手操作时每一个参数背后的真实含义、每一条报错信息对应的排查路径、每一次解绑后必须手动清理的隐藏状态。关键词“DPDK”“网卡绑定”“dpdk-devbind.py”“igb_uio”“vfio-pci”“PCI地址”会贯穿全文它们不是术语标签而是你在终端里敲下的每一个字符、看到的每一行输出、需要反复确认的每一个细节。无论你是刚编译完DPDK源码的新手还是正在为线上服务做热升级的老兵只要你还要和物理网卡打交道这篇解析就不是可选项而是必修课。2. 网卡绑定与解绑的整体设计逻辑从“内核托管”到“用户直控”的权力交接2.1 绑定的本质不是“插上USB”而是“移交司法管辖权”很多人初学DPDK时下意识把“绑定网卡”理解成类似Windows里更新驱动的操作——点几下鼠标换一个驱动网卡就能用了。这是巨大的认知偏差。在Linux世界里网卡驱动不是简单的“设备驱动”它是一整套内核空间的资源管理器。当e1000e或ixgbe驱动加载时它不仅初始化了网卡寄存器还做了三件关键的事第一向内核注册net_device结构体让ifconfig能看到eth0第二申请并映射DMA内存区域建立CPU与网卡之间的数据搬运通道第三注册中断处理函数一旦网卡收到包就触发内核软中断去skb分配、协议栈解析。这三件事构成了内核对网卡的“司法管辖权”。而DPDK要做的恰恰是把这三项权力全部剥离。绑定操作dpdk-devbind.py -b vfio-pci 0000:02:00.0的实质是发起一次内核模块热替换先让原驱动如ixgbe主动释放它所占有的所有资源——包括解除对PCI配置空间的锁定、释放已申请的DMA内存、注销中断号然后由新的UIO驱动vfio-pci或igb_uio接管同一块PCI设备但只做最精简的事提供用户态mmap接口、透传中断信号、允许直接读写设备寄存器。它不注册net_device不参与任何协议栈甚至不关心你收的是IP包还是自定义帧。这种“极简主义”正是性能的来源也是风险的源头——因为一旦移交过程出错比如原驱动没完全释放内存新驱动mmap时就会触发-ENOMEM错误或者中断号被其他设备占用vfio-pci就无法完成中断重映射导致后续rte_eth_dev_start()永远卡在等待link up状态。提示你可以把整个绑定过程想象成一场“法院移交”。dpdk-devbind.py不是快递员而是执行法官。它先向原管辖法院内核驱动下达“立即停职、封存卷宗、移交案卷”的裁定unbind再向新法院UIO驱动签发“准予立案、启用独立档案室、不受理旧案”的许可bind。中间任何一环文书不全移交就失败。2.2 为什么必须有“解绑”——DPDK不是独裁者而是临时工很多教程只教你怎么绑定却很少强调解绑的必要性。有人觉得“我绑好了程序跑起来了干嘛还要解绑” 这种想法在测试环境可能没问题但在生产环境中极其危险。原因有三第一资源泄漏不可逆。DPDK应用崩溃或异常退出时它通过mmap映射的hugepage内存、申请的DMA缓冲区、注册的中断句柄并不会自动归还。内核认为这些资源仍被“某个用户态进程”持有但该进程PID已消失变成孤儿资源。多次这样的崩溃后/proc/meminfo里的HugePages_Free会持续下降最终导致新DPDK实例启动失败报错Cannot allocate memory。此时唯一可靠的清理方式就是解绑网卡——vfio-pci驱动卸载时会强制回收所有关联的DMA映射和中断资源。第二调试与回滚的刚需。当你发现DPDK转发延迟突增需要快速判断是应用逻辑问题还是网卡硬件问题时最直接的方法就是解绑网卡用ethtool -S eth0查看原生统计计数器如rx_discards_phy表示物理层丢包。如果网卡一直绑在vfio-pci下这些计数器根本不可见。同理线上升级DPDK版本前必须先解绑旧驱动、加载新驱动、再重新绑定否则新旧驱动混用会导致不可预测的硬件行为。第三系统稳定性兜底。某些服务器BIOS存在PCIe AERAdvanced Error Reporting缺陷当DPDK应用频繁读写网卡寄存器时可能触发AER错误并导致整个PCIe Root Port复位。如果网卡始终绑定在vfio-pci下内核无法捕获并处理该错误系统可能直接hang死。而解绑后网卡回归ixgbe驱动内核能通过标准AER机制上报错误、隔离故障设备保住整机可用性。2.3 UIO驱动选型igb_uiovsvfio-pci不是性能竞赛而是权限博弈DPDK官方支持两种主流UIO驱动igb_uio基于传统UIO框架和vfio-pci基于VFIO框架。网上充斥着“vfio-pci更安全”“igb_uio性能更好”的模糊说法这极易误导。真相是二者性能差异在现代CPU上几乎可以忽略1%真正的区别在于内核权限模型。igb_uio工作在root权限下它通过/dev/uioX设备文件暴露mmap接口。这意味着任何能读写该设备文件的进程比如一个被入侵的普通用户进程理论上都能直接访问网卡寄存器——这是严重的安全隐患。而vfio-pci则利用Linux内核的IOMMU子系统为每个DPDK进程创建独立的DMA地址空间并通过/dev/vfio/vfio进行严格的权限检查。即使恶意进程获得了/dev/vfio/vfio的fd没有正确的IOMMU group权限它依然无法mmap网卡内存。因此选型逻辑非常清晰开发/测试环境用igb_uio。它编译简单无需开启IOMMU、加载快捷insmod igb_uio.ko、调试友好dmesg日志详细适合快速验证逻辑。生产环境必须用vfio-pci。它要求BIOS中开启VT-d/AMD-Vi且网卡必须位于独立的IOMMU group中可通过lspci -v查看IOMMU group字段但这换来的是企业级的安全隔离能力。注意vfio-pci的加载顺序有严格依赖。必须先加载vfio主模块再加载vfio_iommu_type1最后才是vfio_pci。缺任何一个modprobe vfio-pci都会静默失败。建议用modprobe -r vfio_pci modprobe vfio modprobe vfio_iommu_type1 modprobe vfio_pci四步显式加载避免依赖链断裂。3. 核心细节解析绑定与解绑命令背后的完整技术链条3.1dpdk-devbind.py不是黑盒它是Python封装的PCI设备状态机dpdk-devbind.py常被当作一个“傻瓜命令”使用但它的内部逻辑远比表面复杂。它本质上是一个PCI设备状态同步器其核心任务是在三个状态源之间保持一致内核sysfs状态/sys/bus/pci/devices/0000:02:00.0/driver记录当前哪个驱动在管理该设备DPDK设备白名单/黑名单/etc/dpdk/conf或命令行-w/-b参数声明哪些设备应被DPDK接管用户期望状态命令行参数-b或-u用户明确要求的绑定/解绑动作。执行dpdk-devbind.py -b vfio-pci 0000:02:00.0时脚本会按以下顺序操作校验PCI地址合法性解析0000:02:00.0确认其符合domain:bus:slot.func格式并通过lspci -nn | grep 0000:02:00.0验证设备真实存在检查目标驱动是否已加载读取/sys/module/vfio_pci是否存在若不存在则报错Driver vfio-pci is not loaded验证IOMMU group完整性仅vfio-pci调用get_iommu_group_number()遍历/sys/bus/pci/devices/0000:02:00.0/iommu_group/devices/确保该group内无其他非DPDK设备如集成声卡、USB控制器。若有则拒绝绑定报错Device is in same IOMMU group as non-DPDK devices执行解绑如果需要若当前driver链接指向ixgbe则向/sys/bus/pci/devices/0000:02:00.0/driver/unbind写入PCI地址触发内核驱动卸载执行绑定向/sys/bus/pci/drivers/vfio-pci/bind写入PCI地址触发vfio-pci驱动probe状态确认再次读取/sys/bus/pci/devices/0000:02:00.0/driver确认其已指向vfio-pci并检查/sys/bus/pci/devices/0000:02:00.0/vendor等属性是否可读验证mmap权限。这个过程中的每一步都可能因环境差异而失败。例如第3步某次我在一台Dell R740服务器上绑定X710网卡时dpdk-devbind.py反复报IOMMU group冲突。lspci -tv显示该网卡与板载SATA控制器同属group 13。解决方案不是强行绕过检查而是进入BIOS关闭SATA Controller将其从PCIe拓扑中移除从而让X710获得独立group。这说明dpdk-devbind.py的报错本质是硬件拓扑与内核驱动模型的冲突告警而非脚本本身的bug。3.2 PCI地址的三种表达形式别再靠lspci截图硬记了新手最容易栽跟头的地方就是PCI地址写错。dpdk-devbind.py接受三种格式但它们的适用场景和容错性天差地别地址格式示例解析方式容错性推荐场景标准BDF格式0000:02:00.0直接匹配/sys/bus/pci/devices/下的目录名高精确匹配所有场景首选简写BDF格式02:00.0自动补全domain为0000中domain默认为0快速测试需确认domain为0设备标识符0000:02:00.0,device8086:1572先按BDF定位再校验vendor:device ID最高双重校验生产环境防插错槽位其中device8086:1572中的8086是Intel的vendor ID1572是X710网卡的device ID可通过lspci -nn | grep Ethernet查得。这种写法的价值在于假设你把一张X710网卡从02:00.0槽位拔出插到03:00.0如果脚本里写的是02:00.0绑定必然失败但如果写的是0000:02:00.0,device8086:1572dpdk-devbind.py会先尝试02:00.0失败后自动扫描所有PCI设备找到第一个vendor:device匹配的设备即03:00.0然后对其绑定。这在自动化部署脚本中极为实用。实操心得我写了一个小工具find_dpdk_nic.py它会自动扫描所有以太网设备过滤掉虚拟设备veth,docker0输出带device ID的完整绑定命令。核心逻辑只有三行for dev in glob(/sys/bus/pci/devices/*/net/*): if os.path.exists(f{dev}/device/vendor) and 8086 in open(f{dev}/device/vendor).read(): bdf dev.split(/)[5] print(fdpdk-devbind.py -b vfio-pci {bdf},device8086:1572)这样每次部署前运行一次复制输出命令执行彻底告别手输地址错误。3.3vfio-pci绑定后的关键验证步骤别只看dmesg就以为成功了绑定命令返回Success不代表DPDK应用一定能用。必须执行以下四级验证缺一不可第一级sysfs状态验证# 检查驱动绑定是否生效 ls -l /sys/bus/pci/devices/0000:02:00.0/driver # 正确输出应为driver - ../../../bus/pci/drivers/vfio-pci # 检查IOMMU group是否正确 cat /sys/bus/pci/devices/0000:02:00.0/iommu_group/name # 应输出类似IOMMU Group 12且该group内只有此网卡第二级hugepage与内存验证# 确认hugepage已挂载且足够 grep -i huge /proc/meminfo # 输出应包含HugePages_Total: 1024根据DPDK配置调整 # 检查DPDK能否访问hugepage sudo ./build/app/testpmd -c 0x3 -n 4 -- -i # 若启动成功输入show port info all应看到端口状态为down未启动但Link status为unknown说明DPDK已识别设备第三级中断与DMA验证# 查看中断是否被vfio-pci接管 cat /proc/interrupts | grep 0000:02:00.0 # 正确输出应包含vfio-pci字样而非ixgbe # 检查DMA地址空间是否可读 sudo cat /sys/bus/pci/devices/0000:02:00.0/resource | head -5 # 第0行BAR0应显示非零的size如0x0000000000020000且cat不报错第四级硬件寄存器探针验证终极手段当以上都正常但testpmd仍无法port start时可能是BIOS设置问题。此时需用setpci直接读网卡寄存器# 读取网卡设备ID应为1572 sudo setpci -s 0000:02:00.0 0x02.w # 读取MAC地址寄存器前6字节 sudo setpci -s 0000:02:00.0 0x5400.b # 若返回Permission denied说明vfio-pci未获得足够权限若返回全0说明硬件未响应需检查BIOS中PCIe ASPM/L1 Substates是否禁用这四级验证是我在线上巡检时的标准SOP。曾有一次dmesg显示vfio-pci加载成功但testpmd启动后端口始终link down。按此流程查到第四级setpci读0x5400返回00000000立刻意识到是BIOS中PCIe Power Management被开启强制网卡进入L1低功耗状态。关闭该选项后问题瞬间解决。4. 实操过程详解从零开始完成一次安全、可回滚的绑定/解绑全流程4.1 环境准备五步筑基避免90%的绑定失败在执行任何绑定操作前必须完成以下五步环境初始化。跳过任意一步都可能在后续步骤中付出数小时的排查代价。第一步确认内核版本与配置兼容性DPDK 22.11要求内核≥4.18且必须启用以下配置# 检查关键配置项 zcat /proc/config.gz | grep -E (VFIO|IOMMU|UIO|HUGEPAGE) 2/dev/null || cat /boot/config-$(uname -r) | grep -E (VFIO|IOMMU|UIO|HUGEPAGE)必须确保输出包含CONFIG_VFIO_IOMMU_TYPE1mVFIO基础CONFIG_INTEL_IOMMUy或CONFIG_AMD_IOMMUyIOMMU支持CONFIG_HUGETLB_PAGEy大页支持CONFIG_UIOmUIO框架igb_uio所需若缺失需重新编译内核或更换发行版推荐Ubuntu 22.04 LTS或CentOS Stream 9。第二步BIOS固件预检重启进入BIOS确认以下三项已启用VT-dIntel平台或AMD-ViAMD平台这是vfio-pci工作的物理基础Above 4G Decoding允许PCIe设备使用超过4GB的地址空间避免32位DMA地址冲突SR-IOV Support如需使用VF虽然基础绑定不依赖SR-IOV但开启后能提升IOMMU group划分的灵活性。第三步hugepage内存预分配不要等到DPDK启动时再分配应在系统启动时就固化# 编辑/etc/default/grub添加hugepage参数 GRUB_CMDLINE_LINUX_DEFAULT... default_hugepagesz1G hugepagesz1G hugepages4 # 更新grub并重启 sudo update-grub sudo reboot # 启动后验证 grep -i huge /proc/meminfo # 应显示HugePages_Total: 4, HugePages_Free: 4, Hugepagesize: 1048576 kB注意hugepages4表示分配4个1GB大页总内存4GB。DPDK应用实际使用的内存大小如-m 2048不能超过此值。第四步加载vfio-pci驱动并设置权限# 加载驱动按顺序不可省略 sudo modprobe vfio sudo modprobe vfio_iommu_type1 sudo modprobe vfio_pci # 设置用户组权限避免每次都要sudo sudo groupadd dpdk sudo usermod -a -G dpdk $USER echo SUBSYSTEMvfio, OWNERroot, GROUPdpdk, MODE0660 | sudo tee /etc/udev/rules.d/50-dpdk-vfio.rules sudo udevadm control --reload-rules # 重新登录使group生效第五步备份原始网络配置绑定操作会令网卡消失导致SSH断连。务必提前备份# 备份网卡配置文件CentOS/RHEL sudo cp /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth0.dpdk.bak # 备份路由表 ip route show /tmp/route.bak # 记录当前网关和DNS nmcli dev show | grep -E (IP4.GATEWAY|IP4.DNS)有了这些备份解绑后可一键恢复网络。4.2 安全绑定流程七步法确保零中断交付现在开始正式绑定。采用“分步验证、即时回滚”的七步法步骤1识别目标网卡# 列出所有以太网设备过滤掉虚拟设备 lspci | grep -i ethernet | grep -v -E (Virtual|veth|docker) # 输出示例 # 02:00.0 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP (rev 02) # 记下BDF0000:02:00.0步骤2确认当前驱动状态# 查看该设备当前绑定的驱动 basename $(readlink /sys/bus/pci/devices/0000:02:00.0/driver) # 若输出ixgbe说明由内核驱动管理若输出vfio-pci说明已绑定跳至步骤6步骤3解绑原驱动如有# 安全解绑不强制 sudo dpdk-devbind.py -u 0000:02:00.0 # 检查是否成功 ls -l /sys/bus/pci/devices/0000:02:00.0/driver 2/dev/null || echo Unbound successfully # 若报错可能是网卡正被使用如eth0已up先执行sudo ip link set eth0 down步骤4绑定vfio-pci驱动# 使用device ID增强容错性 sudo dpdk-devbind.py -b vfio-pci 0000:02:00.0,device8086:1572 # 验证绑定结果 basename $(readlink /sys/bus/pci/devices/0000:02:00.0/driver) # 应输出 vfio-pci步骤5验证IOMMU group纯净性# 获取group编号 GROUP$(basename $(readlink /sys/bus/pci/devices/0000:02:00.0/iommu_group)) # 列出该group内所有设备 ls /sys/bus/pci/devices/*/iommu_group/$GROUP/ | grep -v 0000:02:00.0 # 若输出为空说明group纯净若有其他设备需按2.3节方法处理步骤6启动DPDK应用验证# 以最小配置启动testpmd sudo ./build/app/testpmd -c 0x3 -n 4 -- -i # 在testpmd命令行中输入 # testpmd port attach 0000:02:00.0 # 若提示no such device说明绑定失败 # testpmd show port info all # 查看端口状态 # 正常应显示Link status: down, Link speed: 0 Mbps步骤7记录绑定指纹为回滚留痕# 生成唯一绑定指纹 echo BIND_FINGERPRINT_$(date %s): $(lspci -vv -s 0000:02:00.0 | grep -E Subsystem|Kernel driver) | sudo tee -a /var/log/dpdk-bind.log # 该指纹包含时间戳和硬件特征解绑时可据此确认是否操作同一设备4.3 安全解绑流程四步回滚确保业务零感知解绑不是绑定的逆序而是一次独立的、需谨慎规划的操作。尤其当DPDK应用仍在运行时强制解绑会导致应用崩溃甚至系统panic。步骤1优雅停止DPDK应用# 若应用是testpmd按CtrlC退出 # 若是自研应用确保其调用rte_eth_dev_stop()和rte_eal_cleanup() # 检查进程是否已退出 ps aux | grep testpmd # 若仍有残留进程用sudo kill -9 强制终止步骤2卸载vfio-pci驱动关键# 这是解绑前最易被忽略的一步 sudo modprobe -r vfio_pci sudo modprobe -r vfio_iommu_type1 sudo modprobe -r vfio # 卸载后/dev/vfio/目录应消失 ls /dev/vfio/ 2/dev/null || echo vfio modules unloaded注意dpdk-devbind.py -u命令只会解绑设备但不会卸载驱动。若不手动卸载vfio模块会持续占用IOMMU资源导致后续绑定其他设备失败。步骤3解绑设备并恢复内核驱动# 解绑设备 sudo dpdk-devbind.py -u 0000:02:00.0 # 重新绑定ixgbe驱动 sudo dpdk-devbind.py -b ixgbe 0000:02:00.0 # 验证 basename $(readlink /sys/bus/pci/devices/0000:02:00.0/driver) # 应输出 ixgbe步骤4恢复网络服务# 重启NetworkManager或network服务 sudo systemctl restart NetworkManager # 或对于传统网络 sudo systemctl restart network # 验证网络恢复 ping -c 3 8.8.8.8 # 若失败使用4.1节备份的配置文件恢复 sudo cp /etc/sysconfig/network-scripts/ifcfg-eth0.dpdk.bak /etc/sysconfig/network-scripts/ifcfg-eth0 sudo systemctl restart network5. 常见问题与排查技巧实录那些官方文档不会写的血泪经验5.1 绑定失败十大报错及根因分析报错信息根本原因排查命令解决方案Driver vfio-pci is not loadedvfio模块未加载或加载顺序错误lsmod | grep vfio按vfio → vfio_iommu_type1 → vfio_pci顺序modprobeDevice is in same IOMMU group as non-DPDK devicesBIOS中IOMMU未开启或PCIe拓扑导致设备共groupdmesg | grep -i iommulspci -tv开启BIOS VT-d或禁用冲突设备如SATA控制器Cannot bind to driver vfio-pci设备正被内核驱动使用如eth0已uplsof /sys/bus/pci/devices/0000:02:00.0sudo ip link set eth0 down后再绑定No free hugepages reportedhugepage未分配或数量不足grep -i huge /proc/meminfo检查/etc/default/grub中hugepage参数重启Failed to initialize devicetestpmd启动时找不到设备sudo ./build/app/testpmd -c 0x3 -n 4 -- -i检查/dev/vfio/权限确认用户属于dpdk组Segmentation faultDPDK应用与内核版本不兼容ldd ./build/app/testpmd | grep libc重新编译DPDK指定-Dlib.clangfalseLink status: down但物理链路正常网卡firmware版本过旧sudo ethtool -i eth0 | grep firmware升级firmware至DPDK兼容版本如X710需≥6.0vfio-pci: probe of 0000:02:00.0 failed with error -22设备ID不匹配或firmware锁死sudo lspci -nn -s 0000:02:00.0检查device参数是否正确或重置firmwareCannot allocate memoryhugepage充足IOMMU DMA地址空间耗尽dmesg | tail -20重启系统或卸载所有vfio模块后重试testpmd show port info all显示Port 0: No such deviceBDF地址写错或设备不存在lspci | grep 02:00用lspci -tv确认设备真实BDF注意domain是否为00005.2 那些年踩过的坑独家避坑指南坑1dpdk-devbind.py的缓存陷阱dpdk-devbind.py会缓存设备状态到/var/run/dpdk-devbind.cache。当网卡热插拔后缓存未更新导致-s参数列出的设备列表陈旧。解决方案每次操作前加--no-cache参数或手动删除缓存文件。坑2vfio-pci与kvm的IRQ冲突在KVM宿主机上若同时运行大量虚拟机vfio-pci可能无法获取足够的中断号。dmesg会报vfio: unable to map interrupt。此时需在/etc/default/grub中添加intel_iommuon iommupt并重启。坑3NUMA节点亲和性误判DPDK应用默认在socket 0上分配内存但网卡可能插在socket 1的PCIe插槽。testpmd启动后port start失败dmesg显示DMA mapping failed。解决方案启动时显式指定socketsudo ./testpmd -c 0x3 -n 4 --socket-mem1024,0 -- -i其中--socket-mem1024,0表示在socket 0分配1024MB--socket-mem0,1024表示在socket 1分配。坑4ethtool在绑定后失效的真相很多人发现绑定后ethtool -i eth0报No such device以为网卡坏了。其实这是正常现象——ethtool只能与内核驱动通信而DPDK网卡已脱离内核管理。要查看DPDK网卡信息必须用testpmd的show port info all命令。坑5解绑后网卡MAC地址丢失某次解绑后ip link show eth0显示MAC为00:00:00:00:00:00。原因是ixgbe驱动未正确恢复EEPROM中的MAC。解决方案手动设置sudo ip link set eth0 address $(cat /sys/class/net/eth0/address)或重启ixgbe驱动sudo modprobe -r ixgbe sudo modprobe ixgbe。5.3 生产环境黄金 checklist上线前必做十二项验证为确保DPDK服务稳定上线我总结了一份十二项硬性checklist每项都对应一个真实故障案例✅BIOS VT-d/AMD-Vi 已启用曾因未开启导致vfio加载失败✅/proc/cmdline包含intel_iommuon内核启动参数缺失✅dmesg | grep -i iommu输出IOMMU enabledIOMMU未真正激活✅lspci -vv -s 0000:02:00.0 | grep IOMMU显示IOMMU group: 12设备确属独立group✅ **cat /proc/meminfo | grep Huge显示 HugePages_Free