Date: Tue, 7 Mar 2017 13:45:10 +0100
From: Mark Brown <broonie@kernel.org>
To: Tejun Heo <tj@kernel.org>
Cc: Harald Geyer <harald@ccbib.org>, Liam Girdwood <lgirdwood@gmail.com>,
        Lai Jiangshan <jiangshanlai@gmail.com>, linux-kernel@vger.kernel.org
Message-ID: <20170307124510.v7k56nqjr7wshuea@sirena.org.uk>
References: <1487785285-3567-1-git-send-email-harald@ccbib.org>
 <20170222182111.4jajk2ed52okx323@sirena.org.uk>
 <E1cgdBA-0000LS-VU@stardust.g4.wien.funkfeuer.at>
 <20170223173449.c747nrfr3oxrjrr7@sirena.org.uk>
 <20170306222212.GM26127@htj.duckdns.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="6dfzu6gk47crbolu"
Content-Disposition: inline
In-Reply-To: <20170306222212.GM26127@htj.duckdns.org>
User-Agent: NeoMutt/20170113 (1.7.2)
Subject: Re: [PATCH 1/2] workqueue: Add new function mod_fwd_delayed_work()
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2520
Lines: 57


--6dfzu6gk47crbolu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Mar 06, 2017 at 05:22:12PM -0500, Tejun Heo wrote:
> On Thu, Feb 23, 2017 at 09:34:49AM -0800, Mark Brown wrote:

> > It is *very* non-obvious that mod_delayed_work() will have a problem
> > from the documentation, there's "mod_delayed_work_on() on local CPU" as
> > the body of the description but honestly I'm struggling to tell if
> > that's even there intentionally or anything other than an implementation
> > detail.  I'd expect to see some words describing the situations where it
> > can be used or something, both the name and the lack of any information
> > about issues suggest it's the default thing and will work safely.

> What the mod function is implemneting is "whoever wins (runs the last)
> determines the timeout".  It is a bit unwiedly because unlike the
> timer, workqueue delay takes duration instead of the absoulte time
> making coordinating from the user side trickier.

Ah, OK.  That's what the regulator API was looking for (the timeout is
always the same, we just want to kick the starting point into the
future).  We're not trying to reduce timeouts, only increase them.

> > I suspect people are just using mod_delayed_work(), not realising that
> > there are restrictions.  I'm thinking that perhaps it should be fixed
> > to be safe for calling from different contexts and a new function with
> > the existing behaviour added, that seems less error prone.

> I don't think it's a matter of "fixing" the existing
> mod_delayed_work().  What the new function is implementing wouldn't
> fit use cases where the timeout should only be shortened (IIRC,
> writeback code does that).

> I'm not against adding new interface to handle it better but I think
> it makes more sense to add both directions.  How about adding
> expedite_delayed_work_on() and postpone_delayed_work_on()?

That works for me.

--6dfzu6gk47crbolu
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAli+q1YACgkQJNaLcl1U
h9C2Xgf/e7PriHW0bpYJrwhdL0HhK76H2smULCpNzzcEepeBpEIqWOMN0zynUXS+
GQEz/Uh7GVhn4HSNeIIrRTVuPhHu2+7LW8eBZoIIw6wtF9dr/wSp+cnbb9P6h7Zp
HeQNEfYTbeQjTv3TsbZeWgPxeA2pisER+lY4pEpUCoSLQNnhca4i4c6zxUTi+uBm
ixpW/0cKkwI2iBGYNR5gThLJ88EOj6J4CmxywvXc1bhi+cK55WgLJ3E8kJ5fm8JU
OxZMApiUQtoL7Bth8QhHoyehQyrEowSXWUFZI0GXHeBDgo+BZU8azAWaLFkSvTJI
o/em95wt2V2Ujr/NcJvTgNG1GBZIjA==
=irK2
-----END PGP SIGNATURE-----

--6dfzu6gk47crbolu--