linux-kernel - Re: Is it ok for deferrable timer wakeup the idle cpu?

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]

Message-ID: <CAKohpo=qQJwgDpzJMtk-PN6PBB_1KsSXZ_tYrVLOz_9Qzs=gsA@mail.gmail.com>
Date:	Mon, 3 Feb 2014 13:49:26 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Preeti Murthy <preeti.lkml@...il.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Lei Wen <adrian.wenl@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Preeti U Murthy <preeti@...ux.vnet.ibm.com>
Subject: Re: Is it ok for deferrable timer wakeup the idle cpu?

On 29 January 2014 10:57, Preeti Murthy <preeti.lkml@...il.com> wrote:
> How about simplifying this design by doing the below?
>
> 1. Since anyway cpufreq governors monitor load on the cpu once every
> 5ms, *tie it with tick_sched_timer*, which also gets deferred when the cpu
> enters nohz_idle.

Its configurable. We can change sampling time to whatever we want. Some
might be selecting it as 30 ms.

> 2. To overcome the problem of running this job of monitoring the load
> on every cpu, have the *time keeping* cpu do it for you.
>
> The time keeping cpu has the property that if it has to go to idle, it will do
> so and let the next cpu that runs the periodic timer become the time keeper.
> Hence no cpu is prevented from entering nohz_idle and the cpu that is busy
> and first executes periodic timer will take over as the time keeper.
>
> The result would be:
>
> 1. One cpu at any point in time will be monitoring cpu load, at every sched tick
> as long as its busy. If it goes to sleep, then it gives up this duty
> and enters idle.
> The next cpu that runs the periodic timer becomes the cpu to monitor the load
> and will continue to do so as long as its busy. Hence we do not miss monitoring
> the cpu load.
>
> 2. This will avoid an additional timer for cpufreq.
>
> 3. It avoids sending IPIs each time this timer gets modified since there is just
> one CPU doing the monitoring.
>
> 4. The downside to this could be that we are stretching the functions of the
>  periodic timer into the power management domain which does not seem like
> the right thing to do.

Looks good, but AFAIK timerkeeper is still to be implemented? Also the best
solution is to get rid of this timer completely by getting inputs from
scheduler.
Probably some ARM/Linaro folks are working on it.
--
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/