Re: [patch 2/3] pvclock: detect watchdog reset at pvclock read

[Don Zickus]

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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/