[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1445025093-32639-1-git-send-email-cmetcalf@ezchip.com>
Date: Fri, 16 Oct 2015 15:51:33 -0400
From: Chris Metcalf <cmetcalf@...hip.com>
To: Andrew Morton <akpm@...ux-foundation.org>,
Christoph Lameter <cl@...ux.com>,
Michal Hocko <mhocko@...e.cz>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Lai Jiangshan <jiangshanlai@...il.com>,
Shaohua Li <shli@...com>, linux-mm <linux-mm@...ck.org>,
Tejun Heo <tj@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
CC: Chris Metcalf <cmetcalf@...hip.com>
Subject: [PATCH] vmstat_update: ensure work remains on the same core
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 <cmetcalf@...hip.com>
---
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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists