Messages in this thread | | | Subject | Re: RT and Cascade interrupts | From | Trond Myklebust <> | Date | Sun, 29 May 2005 06:58:28 -0700 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |