lkml.org 
[lkml]   [2015]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [GIT PULL] workqueue fixes for v4.3-rc5
From
On Wed, Oct 14, 2015 at 12:02 PM, Tejun Heo <tj@kernel.org> wrote:
>
> But wasn't add_timer() always CPU-local at the time? add_timer()
> allowing cross-cpu migrations came way after that.

add_timer() has actually never been "local CPU only" either.

What add_timer() does is to keep the timer on the old CPU timer wheel
if it was active, and if it wasn't, put it on the current CPU timer
wheel.

So again, by pure *accident*, if you don't end up ever modifying an
already-active timer, then yes, it ended up being local. But even
then, things like suspend/resume can move timers around, afaik, so
even then it has never been a real guarantee.

And I see absolutely no sign that the local cpu case has ever been intentional.

Now, obviously, that said there is obviously at least one case that
seems to have relied on it (ie the mm/vmstat.c case), but I think we
should just fix that.

If it turns out that there really are *lots* of cases where
"schedule_delayed_work()" expects the work to always run on the CPU
that it is scheduled on, then we should probably take your patch just
because it's too painful not to.

But I'd like to avoid that if possible.

Linus


\
 
 \ /
  Last update: 2015-10-14 21:41    [W:0.071 / U:1.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site