[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <48E55FE5.40108@nortel.com>
Date: Thu, 02 Oct 2008 17:57:25 -0600
From: "Chris Friesen" <cfriesen@...tel.com>
To: Ingo Molnar <mingo@...e.hu>,
Linux kernel <linux-kernel@...r.kernel.org>,
Steven Rostedt <rostedt@...dmis.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: [bug report] sched: stop_machine() usage causes load balancer to
misbehave
I mentioned before that ftrace (specifically the ftraced daemon) seems
to be interfering with the load balancer. After some experimenting, it
appears that any regular calls to stop_machine() will end up confusing
the load balancer.
As an experiment, I disabled ftraced (which would normally result in
correct load balancing) but added a single kernel thread which simply
runs the following loop, where "chrisd2" is a dummy function.
while(1) {
set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(HZ);
stop_machine(chrisd2, NULL, NULL);
}
With the modified kernel, my testcase shows that the load balancer
doesn't balance--all tasks remain on one cpu while the other one stays idle.
Most of the users of stop_machine() (kprobes on s390, cpu hotplug,
module load/unload, numa_zonelist_order, etc.) don't seem to be called
on a regular basis. Only ftrace behaves this way, which is why it
appeared to be the source of the problem.
I haven't tracked down the specific reasons for the misbehaviour, but it
seems undesirable.
Anyone have any ideas what might be causing this? Is it a problem with
the load balancer, or an unavoidable consequence of what stop_machine()
is doing?
Thanks,
Chris
--
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