1) This might be happening because the IPI was sent to a offline CPU (just one example of miss-synchronization from flush_tlb_others_ipi logic) during a shutdown process (as discussed in the thread: https://lkml.org/lkml/2012/7/19/53)
At that time the fix wasn't picked because the IPI mechanism for flushing other cpu's TLB was being changed to what we have nowadays, the smp_call_function_many called by "flush_tlb_others". commit 52aec3308db85f4e9f5c8b9f5dc4fbd0138c6fa4 Author: Alex Shi <[email protected]> Date: Thu Jun 28 09:02:23 2012 +0800 x86/tlb: replace INVALIDATE_TLB_VECTOR by CALL_FUNCTION_VECTOR Is the one refactoring this code and probably the responsible for fixing this erratic behavior. OR 2) MOST LIKELY, because the IPI was not delivered to a "context switched" virtual CPU on the host side (as discussed in: https://lkml.org/lkml/2012/6/4/24), causing the running CPU to spin waiting for the other cpu to ACK something did not arrive to it. - Benchmark tool observing issues with flush_tlb_others_ipi on a workload similar to a "message broker" (like this case): http://www.kernelhub.org/?p=2&msg=1209 - First idea of paravirt TLB flushes to avoid CPUs to stay spinning waiting for IPIs to be finished on context switched CPUs: http://www.kernelhub.org/?p=2&msg=1218 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1467955 Title: Precise BUG: soft lockup in flush_tlb_others_ipi To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1467955/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
