On Mon, Oct 31, 2016 at 09:37:02AM +0800, Wanpeng Li wrote:
> From: Wanpeng Li <wanpeng.li@xxxxxxxxxxx>
>
> | RCU used illegally from idle CPU!
> | rcu_scheduler_active = 1, debug_locks = 0
> | RCU used illegally from extended quiescent state!
> | no locks held by swapper/1/0.
> |
> | [<ffffffff9d492b95>] do_trace_write_msr+0x135/0x140
> | [<ffffffff9d06f860>] native_write_msr+0x20/0x30
> | [<ffffffff9d065fad>] native_apic_msr_eoi_write+0x1d/0x30
> | [<ffffffff9d05bd1d>] smp_reschedule_interrupt+0x1d/0x30
> | [<ffffffff9d8daec6>] reschedule_interrupt+0x96/0xa0
Please remove the text between [] and the offsets after "+..." - those
are useless in a commit message.
> Reschedule interrupt may be called in cpu idle state. This causes lockdep
s/cpu/CPU/
> check warning above.
>
> As Peterz pointed out:
>
> | So now we're making a very frequent interrupt slower because of debug
> | code.
> |
> | The thing is, many many smp_reschedule_interrupt() invocations don't
> | actually execute anything much at all and are only send to tickle the
s/send/sent/
> | return to user path (which does the actual preemption).
> |
> | Having to do the whole irq_enter/irq_exit dance just for this unlikely
> | debug case totally blows.
>
> This patch converts x2apic write eoi msr to notrace to avoid the debug
> codes splash and reverts irq_enter/irq_exit dance to avoid to make a very
> frequent interrupt slower because of debug code.
>
> Suggested-by: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> Suggested-by: Paolo Bonzini <pbonzini@xxxxxxxxxx>
> Acked-by: Paolo Bonzini <pbonzini@xxxxxxxxxx>
> Cc: Ingo Molnar <mingo@xxxxxxxxxx>
> Cc: Mike Galbraith <efault@xxxxxx>
> Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx>
> Cc: Borislav Petkov <bp@xxxxxxxxx>
> Signed-off-by: Wanpeng Li <wanpeng.li@xxxxxxxxxxx>
> ---
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
