From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932581AbbI3RN1 (ORCPT ); Wed, 30 Sep 2015 13:13:27 -0400 Received: from mail-yk0-f177.google.com ([209.85.160.177]:34214 "EHLO mail-yk0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932513AbbI3RNY (ORCPT ); Wed, 30 Sep 2015 13:13:24 -0400 Date: Wed, 30 Sep 2015 13:13:20 -0400 From: Tejun Heo To: Shaohua Li Cc: linux-kernel@vger.kernel.org, Kernel-team@fb.com Subject: Re: [PATCH] workqueue: make sure delayed work run in local cpu Message-ID: <20150930171320.GE2627@mtj.duckdns.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 30, 2015 at 09:05:30AM -0700, Shaohua Li wrote: > My system keeps crash with below message. vmstat_update() schedules a delayed > work in current cpu and expects the work runs in the cpu. > schedule_delayed_work() is expected to make delayed work run in local cpu. The > problem is timer can be migrated with NO_HZ. __queue_work() queues work in > timer handler, which could run in a different cpu other than where the delayed > work is scheduled. The end result is the delayed work runs in different cpu. > The patch makes __queue_delayed_work records local cpu earlier. Where the timer > runs doesn't change where the work runs with the change. > ... > Signed-off-by: Shaohua Li This has been broken since 09. No idea why it wasn't triggering before. Maybe the timer wasn't actually being migrated? Applied to wq/for-4.3-fixes w/ stable tag added. Thanks. -- tejun