On 2016年09月20日 23:36, Jan Beulich wrote:
>> The precondition of process_pending_softirq() working in the debug key
>> > handler is that timer interrupt arrives on time and nmi_timer_fn() can
>> > run to update nmi_timer_ticks before watchdog timeout.
Process_pending_softirq() in debug key handler is mainly to deal with
timer softirq to update nmi_timer_ticks in order to avoid NMI watchdog.
If there is no timer interrupt arriving for long time,
process_pending_softirq() here is meaningless and NMI watchdog still
will be timeout.
>> > When a timer interrupt arrives, timer_softirq_action() will run all
>> > expired timer handlers before programing next timer interrupt via
>> > reprogram_timer(). If a timer handler runs too long E,G >5s(Time for
>> > watchdog timeout is default to be 5s.), this will cause no timer
>> > interrupt arriving within 5s and nmi_timer_fn() also won't be called.
>> > Does this make sense to you?
> Partly. I continue to think that the sequence
> some keyhandler
> timer interrupt
> keyhandler continues
> keyhandler calls process_pending_softirq()
Question for your sequence is why there is timer interrupt before
programing timer interrupt.
Actually the sequence in this case is
run key handlers in timer handler
program next timer interrupt
> should, among other things, result in timer_softirq_action() to get
> run. And I don't see the _timer_ handler running for to long here,
> only a key handler.
Key handler may run a long time(E,G >5s) on machine with amount of cpus
or create huge VM. If keyhandler doesn't run for long time,
timer_softirq_action() would also be not necessary since the default
timeout is 5s and nmi timer's interval is 1s.
> Are you perhaps instead suffering from the
> nested instance of timer_softirq_action() not being able to acquire
> its lock?
No, the serial port continues printing timer info before watchdog timeout.
Xen-devel mailing list