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_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. On Wed, Feb 19, 2014 at 11:01 AM, Tejun Heo <tj@xxxxxxxxxx> 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 running. Since we queue flusher work to run either immediately or >> after dirty_writeback_interval we are safe to run queue_delayed_work() >> whenever we want it to run after dirty_writeback_interval and >> mod_delayed_work() whenever we want to run it immediately. > > Ah, okay, so it's always mod on immediate and queue on delayed. Yeah, > that should work. > >> But it's subtle and some interface where we could say queue delayed work >> after no later than X would be easier to grasp. > > Yeah, I think it'd be better if we had something like > mod_delayed_work_if_later(). Hmm... > > Thanks. > > -- > tejun -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
