在虚拟化技术中LHP (Lock Holder Preemption)和LWP (Lock Waiter Preemption)是导致虚拟机性能急剧下降的两个核心痛点。这两个问题主要源于Guest OS客户操作系统和Hypervisor宿主管理程序之间的“信息不对称”。以下是详细的深度解析1. 核心背景自旋锁 (Spinlock) 的假设为了理解 LHP/LWP首先需要理解操作系统内核中常见的自旋锁 (Spinlock)。机制当一个线程或 vCPU想要访问共享资源时如果发现锁被别人拿了它不会进入睡眠Sleep而是会在原地“转圈圈”空循环检查直到锁被释放。物理机上的假设自旋锁是基于一个假设设计的——持有锁的人正在另一个 CPU 上干活很快就会释放锁。因此与其切换上下文进入睡眠开销大不如原地等一会开销小。然而在虚拟化环境中Hypervisor 可能会随时打断抢占任何一个 vCPU 的运行。这破坏了上述假设。2. LHP: 锁持有者被抢占 (Lock Holder Preemption)这是最严重的问题通常被称为“性能杀手”。场景描述vCPU-A获取了一个自旋锁Lock X开始处理临界区代码。Hypervisor突然介入可能是时间片到了或者有更高优先级的 PVM 任务强制暂停了vCPU-A把它踢出了物理 CPUpCPU。此时vCPU-B运行在另一个物理核上也想要获取 Lock X。vCPU-B发现锁被占用了于是开始自旋Spinning。后果由于 vCPU-A 处于“休眠”状态它根本无法运行代码来释放锁。vCPU-B不知道 vCPU-A 被暂停了它以为 vCPU-A 还在干活所以 vCPU-B 会一直空转直到它的时间片用完。资源浪费vCPU-B 占用的物理 CPU 处于 100% 满载状态但没有做任何有意义的工作都在空转。如果有 vCPU-C、vCPU-D 也要这个锁它们也会全部卡死。比喻你vCPU-B在厕所门口排队。里面的人vCPU-A进去锁上门后突然被灭霸Hypervisor打了个响指时间停止了。你在门口一直敲门自旋以为他马上就好结果他在里面“冻结”了整整一个小时。你这一个小时的时间完全被浪费了。3. LWP: 锁等待者被抢占 (Lock Waiter Preemption)这是一个关于“延迟”的问题。场景描述vCPU-A持有锁。vCPU-B正在排队等待锁自旋中。Hypervisor认为vCPU-B耗尽了时间片或者为了负载均衡把vCPU-B抢占暂停了。随后vCPU-A释放了锁。后果此时锁是空闲的但vCPU-B已经被挂起了Sleeping/Preempted。直到 Hypervisor 再次调度vCPU-B运行之前这个锁可能一直闲置或者被别人插队。当vCPU-B终于醒来拿到锁时已经过去很久了。影响增加了获取锁的延迟Latency。在实时系统RT中这会导致任务无法在规定时间内完成。比喻叫号机叫到了你的号锁空闲了但你刚才等太久睡着了vCPU-B 被抢占。柜台空着没人办业务资源闲置直到管理员把你叫醒。4. 其他解决方案如果不采用独占核方案通常用以下技术解决 LHPPLE (Pause Loop Exiting): 硬件辅助Intel VT-x / ARM 架构支持。当 CPU 检测到 vCPU 在死循环自旋时会自动触发“VM Exit”退出到 Hypervisor。Hypervisor 意识到“这哥们在傻等”于是主动挂起它去调度那个持有锁的 vCPU。PV Spinlocks (半虚拟化自旋锁): 修改 Guest OS 内核。当 Guest 发现等锁时间太长主动发指令给 Hypervisor“我卡住了请把我挂起Yield让持有锁的兄弟先跑。”Gang Scheduling (群组调度): Hypervisor 保证属于同一个 VM 的所有 vCPU同时被调度上线或同时被下线。这样就不会出现“持有者下线等待者上线”的尴尬局面。总结在虚拟化场景中LHP是导致系统卡顿、CPU 飙高但无产出的元凶。LWP是导致实时性变差、响应变慢的原因。物理隔离是最简单粗暴但也最有效的根治手段。
在虚拟化技术中LHP (Lock Holder Preemption)和LWP (Lock Waiter Preemption)是导致虚拟机性能急剧下降的两个核心痛点。这两个问题主要源于Guest OS客户操作系统和Hypervisor宿主管理程序之间的“信息不对称”。以下是详细的深度解析1. 核心背景自旋锁 (Spinlock) 的假设为了理解 LHP/LWP首先需要理解操作系统内核中常见的自旋锁 (Spinlock)。机制当一个线程或 vCPU想要访问共享资源时如果发现锁被别人拿了它不会进入睡眠Sleep而是会在原地“转圈圈”空循环检查直到锁被释放。物理机上的假设自旋锁是基于一个假设设计的——持有锁的人正在另一个 CPU 上干活很快就会释放锁。因此与其切换上下文进入睡眠开销大不如原地等一会开销小。然而在虚拟化环境中Hypervisor 可能会随时打断抢占任何一个 vCPU 的运行。这破坏了上述假设。2. LHP: 锁持有者被抢占 (Lock Holder Preemption)这是最严重的问题通常被称为“性能杀手”。场景描述vCPU-A获取了一个自旋锁Lock X开始处理临界区代码。Hypervisor突然介入可能是时间片到了或者有更高优先级的 PVM 任务强制暂停了vCPU-A把它踢出了物理 CPUpCPU。此时vCPU-B运行在另一个物理核上也想要获取 Lock X。vCPU-B发现锁被占用了于是开始自旋Spinning。后果由于 vCPU-A 处于“休眠”状态它根本无法运行代码来释放锁。vCPU-B不知道 vCPU-A 被暂停了它以为 vCPU-A 还在干活所以 vCPU-B 会一直空转直到它的时间片用完。资源浪费vCPU-B 占用的物理 CPU 处于 100% 满载状态但没有做任何有意义的工作都在空转。如果有 vCPU-C、vCPU-D 也要这个锁它们也会全部卡死。比喻你vCPU-B在厕所门口排队。里面的人vCPU-A进去锁上门后突然被灭霸Hypervisor打了个响指时间停止了。你在门口一直敲门自旋以为他马上就好结果他在里面“冻结”了整整一个小时。你这一个小时的时间完全被浪费了。3. LWP: 锁等待者被抢占 (Lock Waiter Preemption)这是一个关于“延迟”的问题。场景描述vCPU-A持有锁。vCPU-B正在排队等待锁自旋中。Hypervisor认为vCPU-B耗尽了时间片或者为了负载均衡把vCPU-B抢占暂停了。随后vCPU-A释放了锁。后果此时锁是空闲的但vCPU-B已经被挂起了Sleeping/Preempted。直到 Hypervisor 再次调度vCPU-B运行之前这个锁可能一直闲置或者被别人插队。当vCPU-B终于醒来拿到锁时已经过去很久了。影响增加了获取锁的延迟Latency。在实时系统RT中这会导致任务无法在规定时间内完成。比喻叫号机叫到了你的号锁空闲了但你刚才等太久睡着了vCPU-B 被抢占。柜台空着没人办业务资源闲置直到管理员把你叫醒。4. 其他解决方案如果不采用独占核方案通常用以下技术解决 LHPPLE (Pause Loop Exiting): 硬件辅助Intel VT-x / ARM 架构支持。当 CPU 检测到 vCPU 在死循环自旋时会自动触发“VM Exit”退出到 Hypervisor。Hypervisor 意识到“这哥们在傻等”于是主动挂起它去调度那个持有锁的 vCPU。PV Spinlocks (半虚拟化自旋锁): 修改 Guest OS 内核。当 Guest 发现等锁时间太长主动发指令给 Hypervisor“我卡住了请把我挂起Yield让持有锁的兄弟先跑。”Gang Scheduling (群组调度): Hypervisor 保证属于同一个 VM 的所有 vCPU同时被调度上线或同时被下线。这样就不会出现“持有者下线等待者上线”的尴尬局面。总结在虚拟化场景中LHP是导致系统卡顿、CPU 飙高但无产出的元凶。LWP是导致实时性变差、响应变慢的原因。物理隔离是最简单粗暴但也最有效的根治手段。
![[Web3] 去中心化基石 - BIP铁三角(BIP32/39/44)](http://pic.xiahunao.cn/yaotu/[Web3] 去中心化基石 - BIP铁三角(BIP32/39/44))
