On Mon, Mar 17, 2014 at 01:53:57PM -0700, dbasehore . wrote:
> It will still be at least be pending after the specified time has
> passed. I'm proposing that we still set the timer. The difference is
> that there is a possibility the work will already be pending when the
> timer goes off. There wil
On Mon, Mar 17, 2014 at 7:40 AM, Tejun Heo wrote:
> Hello,
>
> On Sun, Mar 16, 2014 at 12:13:55PM -0700, dbasehore . wrote:
>> There's already behavior that is somewhat like that with the current
>> implementation. If there's an item on a workqueue, it could run at any
>> time. From the perspectiv
Hello,
On Sun, Mar 16, 2014 at 12:13:55PM -0700, dbasehore . wrote:
> There's already behavior that is somewhat like that with the current
> implementation. If there's an item on a workqueue, it could run at any
> time. From the perspective of the driver/etc. that is using the
> workqueue, there s
On Sat 15-03-14 13:22:53, dbasehore . wrote:
> Resurrecting this for further discussion about the root of the problem.
>
> mod_delayed_work_if_later addresses the problem one way, but the
> problem is still there for mod_delayed_work.
But flusher works care about only that one way, don't they? W
Also, the difference it would make is fix the issue for when a
delayed_work is used for both immediate work (mod_delayed_work(0)) and
delayed work.
On Sun, Mar 16, 2014 at 12:13 PM, dbasehore . wrote:
> There's already behavior that is somewhat like that with the current
> implementation. If ther
There's already behavior that is somewhat like that with the current
implementation. If there's an item on a workqueue, it could run at any
time. From the perspective of the driver/etc. that is using the
workqueue, there should be no difference between work being on the
workqueue and the kernel tri
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 s
Resurrecting this for further discussion about the root of the problem.
mod_delayed_work_if_later addresses the problem one way, but the
problem is still there for mod_delayed_work. I think we could take
another approach that doesn't modify the API, but still addresses
(most of) the problem.
mod_
On Tue 11-03-14 11:23:55, Andrew Morton wrote:
> On Wed, 19 Feb 2014 14:01:39 -0500 Tejun Heo wrote:
>
> > Hello, Jan.
> >
> > On Wed, Feb 19, 2014 at 10:27:31AM +0100, Jan Kara wrote:
> > > You are the workqueue expert so you may know better ;) But the way I
> > > understand it is that queue_
On Wed, 19 Feb 2014 14:01:39 -0500 Tejun Heo wrote:
> Hello, Jan.
>
> On Wed, Feb 19, 2014 at 10:27:31AM +0100, Jan Kara wrote:
> > You are the workqueue expert so you may know better ;) But the way I
> > understand it is that queue_delayed_work() does nothing if the timer is
> > already runni
Hello, Jan.
On Wed, Feb 19, 2014 at 10:27:31AM +0100, Jan Kara wrote:
> You are the workqueue expert so you may know better ;) But the way I
> understand it is that queue_delayed_work() does nothing if the timer is
> already running. Since we queue flusher work to run either immediately or
> aft
On Tue 18-02-14 17:55:48, Tejun Heo wrote:
> Hello,
>
> On Fri, Feb 14, 2014 at 08:12:17PM -0800, Derek Basehore wrote:
> > bdi_wakeup_thread_delayed used the mod_delayed_work function to schedule
> > work
> > to writeback dirty inodes. The problem with this is that it can delay work
> > that
>
Hello,
On Fri, Feb 14, 2014 at 08:12:17PM -0800, Derek Basehore wrote:
> bdi_wakeup_thread_delayed used the mod_delayed_work function to schedule work
> to writeback dirty inodes. The problem with this is that it can delay work
> that
> is scheduled for immediate execution, such as the work from
On Fri 14-02-14 20:12:17, Derek Basehore wrote:
> bdi_wakeup_thread_delayed used the mod_delayed_work function to schedule work
> to writeback dirty inodes. The problem with this is that it can delay work
> that
> is scheduled for immediate execution, such as the work from sync_inodes_sb.
> This c
14 matches
Mail list logo
