From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756485Ab1BCQUI (ORCPT ); Thu, 3 Feb 2011 11:20:08 -0500 Received: from mail-fx0-f46.google.com ([209.85.161.46]:43078 "EHLO mail-fx0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752448Ab1BCQUG (ORCPT ); Thu, 3 Feb 2011 11:20:06 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=GEJTfuz0rDVUCBeUqPHr4KOJkoN+HwM+zUVdYTTf5IVDMZIhpqat0OOmQNshtvfrk3 RRD5cj4YFbaSiWc8pyvfXLYyHGqeeeuoq6CthmuPW97/Kh/BbLl24IViOmM/5s4GGCE+ GWfrx5HvCn0RcjQ/ZLrSxlM3PCk/aiZj2AKsk= Date: Thu, 3 Feb 2011 17:19:06 +0100 From: Tejun Heo To: Peter Zijlstra Cc: Thomas Gleixner , Linux Kernel Mailing List , Jens Axboe , Faisal Latif , Roland Dreier , Sean Hefty , Hal Rosenstock , Dmitry Torokhov , Alessandro Rubini , Trond Myklebust , Mark Fasheh , Joel Becker , "David S. Miller" , "John W. Linville" , Johannes Berg , Yong Zhang Subject: Re: [PATCH 4/4] workqueue: Remove now superfluous cancel_delayed_work() calls Message-ID: <20110203161906.GG2570@htj.dyndns.org> References: <20110203140940.072679794@chello.nl> <20110203141548.346089735@chello.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110203141548.346089735@chello.nl> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Peter. On Thu, Feb 03, 2011 at 03:09:44PM +0100, Peter Zijlstra wrote: > Since queue_delayed_work() can now deal with existing timers, we don't > need to explicitly call cancel_delayed_work() anymore. This is nice but there's small complication with the way queue_delayed_work() behaves. If a delayed work item is already pending, another queue_delayed_work() doesn't modify the delay whether the new delay is longer or shorter than the current one. The previous patch doesn't really change the behavior as the whole thing is gated with WORK_STRUCT_PENDING_BIT. So, cancel_delayed_work() followed by queue_delayed_work() schedules the work to be executed at the specified time regardless of the current pending state while queue_delayed_work() takes effect iff currently the work item is not pending. The current behavior is weird and it often is easier to use explicit timer + work item if the timer needs to be modified, but it has been that way from the beginning so I don't think changing it would be a good idea. We can introduce a new interface (mod_delayed_work() maybe) for this tho. Thanks. -- tejun