Tejun Heo tj@kernel.org writes:
Hey, guys.
On Wed, Dec 11, 2013 at 02:22:14PM +0100, Frederic Weisbecker wrote:
I fear I don't understand your question. Do you mean why don't we prevent from that bdi writeback work to run when we are in full dynticks mode?
We can't just ignore workqueues and timers callback when they are scheduled otherwise the kernel is going to behave randomly.
OTOH what we can do is to work on these per cpu workqueues and timers and do what's necessary to avoid them to fire, as explained in detail there Documentation/kernel-per-CPU-kthreads.txt
Hmmm... some per-cpu workqueues can be turned into unbound ones and the writeback is one of those.
Ah, looks like the writeback one is already unbound, and configurable from sysfs.
Viresh, add this to your test script, and it should get this workqueue out of the way:
# pin the writeback workqueue to CPU0 echo 1 > /sys/bus/workqueue/devices/writeback/cpumask
Kevin
Currently, this is used for powersaving on mobile but could also be useful for jitter control. In the long term, it could be beneficial to strictly distinguish the workqueues which really need per-cpu behavior and the ones which are per-cpu just for optimization.
There is also the problem of unbound workqueues for which we don't have a solution yet. But the idea is that we could tweak their affinity from sysfs.
Yes, this is a long term todo item but I'm currently a bit too swamped to tackle it myself. cc'ing Lai, who has pretty good knowledge of workqueue internals, and Bandan, who seemed interested in working on implementing default attrs.
Thanks.