Re: RT and Cascade interrupts

Trond Myklebust
2005-05-29T13:58:49Z

su den 29.05.2005 Klokka 15:31 (+0400) skreiv Oleg Nesterov:
> __rpc_execute() calls ->tk_exit and goes to 'restarted' label.
> What if ->tk_exit calls rpc_sleep_on() ? If it is possible, we
> have a race.
>
> CPU_0 (main loop in rpc_execute restarted) CPU_1
>
> rpc_delete_timer:
> if (RPC_IS_QUEUED()) // YES
> return;
> rpc_run_timer:
> rpc_wake_up_task:
> clear_bit(RPC_TASK_QUEUED)
> preemption, or long interrupt
>
> if (!RPC_IS_QUEUED()) // YES
> task->tk_action()
> __rpc_add_timer:
> set_bit(RPC_TASK_HAS_TIMER)
> mod_timer();
> clear_bit(RPC_TASK_HAS_TIMER)
>
> Now we have pending timer without RPC_TASK_HAS_TIMER bit set.

It is possible, but it should be _extremely_ rare. The only cases where
tk_exit() sets a timer are the cases where we call rpc_delay(). In the
existing cases in the kernel, that would be setting timers of 5 seconds
(for the case of JUKEBOX errors) or longer.

These tx_exit()+restart events are very rare in themselves (JUKEBOX
errors only occur if the server needs to do something with a long
latency - such as retrieving a file from an HSM unit), but for that to
coincide with a preemption or interrupt of > 5 seconds inside
__rpc_execute... I'd hate to see those RPC performance figures.

> Is this patch makes any sense?

Yes. I agree the scenario is theoretically possible (so I can queue that
patch up for you). I am not convinced it is a plausible explanation for
what John claims to be seeing, though.

Cheers,
Trond