Messages in this thread | | | Date | Wed, 16 Oct 2013 14:22:09 -0400 | From | Don Zickus <> | Subject | Re: [patch 2/3] pvclock: detect watchdog reset at pvclock read |
| |
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
| |