linux-kernel - Re: [Query] Ticks happen in pair for NO_HZ

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 12 Dec 2013 16:32:25 -0800
From:	Kevin Hilman <khilman@...aro.org>
To:	Tejun Heo <tj@...nel.org>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
	Linaro Networking <linaro-networking@...aro.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	bsd@...hat.com, laijs@...fujitsu.com
Subject: Re: [Query] Ticks happen in pair for NO_HZ_FULL cores ?

Tejun Heo <tj@...nel.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.
--
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/