On Wed, Oct 09, 2013 at 06:26:33PM -0300, Marcelo Tosatti wrote: > From https://lkml.org/lkml/2013/7/3/675: > > "Agree. However, can't see how there is a way around "having custom > kvm/paravirt splat all over", for watchdogs that do: > > 1. check for watchdog resets > 2. read time via sched_clock or xtime. > 3. based on 2, decide whether there has been a longer delay than > acceptable. > > This is the case for the softlockup timer interrupt. So the splat there > is necessary (otherwise any potential notification of vm-pause event > noticed at 2 might be missed because its checked at 1). > > For watchdogs that measure time based on interrupt event (such as hung > task, rcu_cpu_stall, checking for the notification at sched_clock or > lower is fine)." >
Sorry for the delay, I was trying to spend time understanding the problem again. Rik van Riel helped me (as I could just walk over to him). I was trying to figure out if there was a way to convert the softlockup to something more virt-friendly mechanism. I was toying with the idea of having the softlockup use schedule_timeout and then have the touch_softlockup routine keep rescheduling (delay) the timeout. The idea was that if it actually timed out, it was guaranteed to be a lockup. This removed the need for the duration calculation but more importantly, I believe the schedule_timeout routine was guest time aware. But I haven't had the chance to think through the whole thing to know if that was the right way to go or if there was pitfalls. Just busy with other stuff. Regardless, I think this patchset solves a particular problem and I am ok with it (even v2 I believe). Cheers, Don -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
