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 for Android: free password hash cracker in your pocket

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

Message-ID: <20140123133537.GA13345@localhost.localdomain>
Date:	Thu, 23 Jan 2014 14:35:41 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	Lei Wen <adrian.wenl@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	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>
Subject: Re: Is it ok for deferrable timer wakeup the idle cpu?

On Thu, Jan 23, 2014 at 11:22:32AM +0530, Viresh Kumar wrote:
> I think below diff might get this fixed for you, though I am not sure if it
> breaks something else. Probably Thomas/Frederic can answer here.
> If this looks fine I will send it formally again:
> 
> diff --git a/kernel/timer.c b/kernel/timer.c
> index accfd24..3a2c7fa 100644
> --- a/kernel/timer.c
> +++ b/kernel/timer.c
> @@ -940,7 +940,8 @@ void add_timer_on(struct timer_list *timer, int cpu)
>          * makes sure that a CPU on the way to stop its tick can not
>          * evaluate the timer wheel.
>          */
> -       wake_up_nohz_cpu(cpu);
> +       if (!tbase_get_deferrable(timer->base))
> +               wake_up_nohz_cpu(cpu);

So you simply rely on the next tick to see the new timer. This should work with
CONFIG_NO_HZ_IDLE but not with CONFIG_NO_HZ_FULL since the target may be running
without the tick.

Basically, in the case of a deferrable timer you need to manage to call
wake_up_full_nohz_cpu() but not wake_up_idle_cpu().

It should be even possible to spare the IPI in a full dynticks CPU if it is
running idle. But that's an optional bonus because it require some deep
care on complicated races against the call to tick_nohz_idle_exit().

I also realize than when we enqueue a timer on a full nohz CPU, we should set_need_resched()
the target before sending the IPI if it is idle like does wake_up_idle_cpu(). Otherwise the
IPI will be ignored without exiting the idle loop nor reevaluating the tick on irq exit.
If you can fix that along the way, that will be much appreciated.

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/