From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754485AbbJNUYx (ORCPT ); Wed, 14 Oct 2015 16:24:53 -0400 Received: from mail-yk0-f175.google.com ([209.85.160.175]:34783 "EHLO mail-yk0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753461AbbJNUYv (ORCPT ); Wed, 14 Oct 2015 16:24:51 -0400 Date: Wed, 14 Oct 2015 16:24:48 -0400 From: Tejun Heo To: Linus Torvalds Cc: Andrew Morton , Christoph Lameter , Michal Hocko , Linux Kernel Mailing List , Lai Jiangshan , Shaohua Li , linux-mm Subject: Re: [GIT PULL] workqueue fixes for v4.3-rc5 Message-ID: <20151014202448.GE12799@mtj.duckdns.org> References: <20151013214952.GB23106@mtj.duckdns.org> <20151014165729.GA12799@mtj.duckdns.org> <20151014190259.GC12799@mtj.duckdns.org> <20151014193829.GD12799@mtj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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