By using schedule_delayed_work(), we are preferring the local core for the work, but not requiring it. In my task isolation experiments, I saw a nohz_full core's vmstat_update end up running on a housekeeping core, and when the two works ran back-to-back, we triggered the VM_BUG_ON() at the end of the function.
Switch to using schedule_delayed_work_on(smp_processor_id(), ...). Signed-off-by: Chris Metcalf <[email protected]> --- This change that I made a few days ago in my local tree is particularly amusing given that the thread I am appending this email to ("workqueue fixes for v4.3-rc5") also fixes the symptoms of the bug I saw, but I wasn't aware of it until just now. And it took a while for me to track it down! I think this is probably a "belt and suspenders" kind of issue where it makes sense to fix it on both sides of the API, however. mm/vmstat.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/vmstat.c b/mm/vmstat.c index cf7d324f16e2..5c6bd7e5db07 100644 --- a/mm/vmstat.c +++ b/mm/vmstat.c @@ -1369,7 +1369,8 @@ static void vmstat_update(struct work_struct *w) * to occur in the future. Keep on running the * update worker thread. */ - schedule_delayed_work(this_cpu_ptr(&vmstat_work), + schedule_delayed_work_on(smp_processor_id(), + this_cpu_ptr(&vmstat_work), round_jiffies_relative(sysctl_stat_interval)); else { /* -- 2.1.2 -- 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/
