[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140316145951.GB26026@htj.dyndns.org>
Date: Sun, 16 Mar 2014 10:59:51 -0400
From: Tejun Heo <tj@...nel.org>
To: "dbasehore ." <dbasehore@...omium.org>
Cc: Jan Kara <jack@...e.cz>, Alexander Viro <viro@...to.linux.org.uk>,
Andrew Morton <akpm@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Darrick J. Wong" <darrick.wong@...cle.com>,
Kees Cook <keescook@...omium.org>,
linux-fsdevel@...r.kernel.org,
linux-kernel <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
bleung@...omium.org, sonnyrao@...omium.org,
Luigi Semenzato <semenzato@...omium.org>
Subject: Re: [PATCH] backing_dev: Fix hung task on sync
On Sat, Mar 15, 2014 at 01:22:53PM -0700, dbasehore . wrote:
> mod_delayed_work currently removes a work item from a workqueue if it
> is on it. Correct me if I'm wrong, but I don't think that this is
> necessarily required for mod_delayed_work to have the current
> behavior. We should be able to set the timer while a delayed_work is
> currently on a workqueue. If the delayed_work is still on the
> workqueue when the timer goes off, everything is fine. If it has left
> the workqueue, we can queue it again.
What different would that make w.r.t. this issue? Plus, please note
that a work item may wait non-insignificant amount of time pending if
the workqueue is saturated to max_active. Doing the above would make
mod_delayed_work()'s behavior quite fuzzy - the work item is modified
or queued to the specified time but if the timer has already expired,
the work item may execute after unspecified amount of time which may
be shorter than the new timeout. What kind of interface would that
be?
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists