* [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).