Hello, On Wed, Oct 14, 2015 at 01:10:33PM -0700, Linus Torvalds wrote: > At the same time, some of the same issues that are pushing people to > move timers around (put idle cores to deeper sleeps etc) would also > argue for moving delayed work around to other cpus if possible. > > So I agree that there is a push to make timer cpu targets more dynamic > in a way we historically didn't really have. At the same time, I think > the same forces that want to move timers around would actually likely > want to move delayed work around too...
I fully agree. We gotta get this in order sooner or later. I'll try to come up with a transition plan. > > * This makes queue_delayed_work() behave differently from queue_work() > > and when I checked years ago the local queueing guarantee was > > definitely being depended upon by some users. > > Yes. But the delayed work really is different. By definition, we know > that the current cpu is busy and active _right_now_, and so keeping > work on that cpu isn't obviously wrong. > > But it's *not* obviously right to schedule something on that > particular cpu a few seconds from now, when it might be happily asleep > and there might be better cpus to bother.. But in terms of API consistency, it sucks to have queue_work() guarantee local queueing but not queue_delayed_work(). The ideal situation would be updating both so that neither guarantees. If that turns out to be too painful, maybe we can rename queue_delayed_work() so that it signifies its difference from queue_work(). Let's see. > > I do want to get rid of the local queueing guarnatee for all work > > items. That said, I don't think this is the right way to do it. > > Hmm. I guess that for being past rc5, taking your patch is the safe > thing. I really don't like it very much, though. Heh, yeah, I pondered about calling it a happy accident and just sticking with the new behavior. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
