* [PATCH 2/2] nvme: fix the placement of set_current_state to TASK_INTERRUPTIBLE [not found] <51103A15.8010508@linux.intel.com> @ 2013-02-19 15:05 ` Matthew Wilcox 2013-02-19 16:30 ` Arjan van de Ven 0 siblings, 1 reply; 2+ messages in thread From: Matthew Wilcox @ 2013-02-19 15:05 UTC (permalink / raw) On Mon, Feb 04, 2013@02:45:41PM -0800, Arjan van de Ven wrote: > the nvme driver has a kthread that processes certain events periodically. > However, the kthread also gets woken for certain urgent actions. > > The current code does not use the current_state logic correctly; > it calls set_current_state(TASK_INTERRUPTIBLE); right before doing > a schedule_timeout(), with the result that there is a race condition > where a wakeup can get lost, and thus delayed by one second. > > This patch moves the set_current_state(TASK_INTERRUPTIBLE); to before > the place where the queue of outstanding work is checked, to close > the race condition The thing is, that's not a queue of outstanding work, that's the list of devices that exist in the system. Your patch makes the kthread do all of its work in the TASK_INTERRUPTIBLE state, which I don't think is right either (is it?) We could add a flag to indicate that there's urgent work to be done (checked after setting TASK_INTERRUPTIBLE), or just live with the occasional race. Alternatively, we could get rid of the kthread in favour of timers for cancelling commands and a workqueue for dealing with urgent work. I have this on my long-term todo list, but in the absence of having hardware to test with on large-scale systems, I didn't want to make such a large change. ^ permalink raw reply [flat|nested] 2+ messages in thread
* [PATCH 2/2] nvme: fix the placement of set_current_state to TASK_INTERRUPTIBLE 2013-02-19 15:05 ` [PATCH 2/2] nvme: fix the placement of set_current_state to TASK_INTERRUPTIBLE Matthew Wilcox @ 2013-02-19 16:30 ` Arjan van de Ven 0 siblings, 0 replies; 2+ messages in thread From: Arjan van de Ven @ 2013-02-19 16:30 UTC (permalink / raw) On 2/19/2013 7:05 AM, Matthew Wilcox wrote: > On Mon, Feb 04, 2013@02:45:41PM -0800, Arjan van de Ven wrote: >> the nvme driver has a kthread that processes certain events periodically. >> However, the kthread also gets woken for certain urgent actions. >> >> The current code does not use the current_state logic correctly; >> it calls set_current_state(TASK_INTERRUPTIBLE); right before doing >> a schedule_timeout(), with the result that there is a race condition >> where a wakeup can get lost, and thus delayed by one second. >> >> This patch moves the set_current_state(TASK_INTERRUPTIBLE); to before >> the place where the queue of outstanding work is checked, to close >> the race condition > > The thing is, that's not a queue of outstanding work, that's the list > of devices that exist in the system. Your patch makes the kthread do > all of its work in the TASK_INTERRUPTIBLE state, which I don't think is > right either (is it?) eh why not? it counts to load average, but frankly, you're using CPU... you count anyway ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2013-02-19 16:30 UTC | newest] Thread overview: 2+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <51103A15.8010508@linux.intel.com> 2013-02-19 15:05 ` [PATCH 2/2] nvme: fix the placement of set_current_state to TASK_INTERRUPTIBLE Matthew Wilcox 2013-02-19 16:30 ` Arjan van de Ven
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).