On Tue, 2011-04-05 at 10:48 +0200, Peter Zijlstra wrote: > On Tue, 2011-03-22 at 12:35 +0200, Avi Kivity wrote: > >> Here's top with 96 idle guests running: > > On some hacked up 2.6.38 kernel... > > > > Start of perf report -g > > > 55.26% kvm [kernel.kallsyms] [k] __ticket_spin_lock > > > | > > > --- __ticket_spin_lock > > > | > > > |--94.68%-- _raw_spin_lock > > > | | > > > | |--97.55%-- double_rq_lock > > > | | load_balance > > > | | idle_balance > > > | | schedule > > > | | | > > > | | |--60.56%-- schedule_hrtimeout_range_clock > > > | | | schedule_hrtimeout_range > > > | | | poll_schedule_timeout > > > | | | do_select > > > | | | core_sys_select > > > | | | sys_select > > > | | | system_call_fastpath > > Looks like your workload and idle balancing don't much like each-other. > > What I think is happening is that all your 'idle' qemu thingies keep > waking up frequently and because you've got like twice the number of > qemu instances as you've got cpus there's a fair chance you'll have a > cpu with a pending task while another one goes idle. > > (Why does qemu keep waking if its idle? broken NOHZ?) > > So idle balancing is called when the cpu goes idle (context switch to > the idle thread) and tries to steal a pending task from another cpu, > clearly it keeps finding these tasks otherwise it wouldn't try to take > that lock. > > Mike, you build in some idle balance throttle logic, but that seems > defeated here (possible because it keeps finding pending tasks to > migrate? still need morning juice). Hm. Maybe someone set sysctl_sched_migration_cost to 0, or wakeups aren't arriving that frequently is all that pops to mind atm. -Mike -- 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
