linux-kernel - Re: full no_hz: how works arch_irq_work_raise() with tick off on generic implementation

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] [day] [month] [year] [list]

Message-ID: <20150309150949.GB25605@lerouge>
Date:	Mon, 9 Mar 2015 16:09:51 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: full no_hz: how works arch_irq_work_raise() with tick off on
 generic implementation

On Mon, Mar 09, 2015 at 03:09:17PM +0100, Sebastian Andrzej Siewior wrote:
> I just stumbled over this in -RT. The code:
> 
>  87 bool irq_work_queue(struct irq_work *work)
>  88 {
> …
>  96         /* If the work is "lazy", handle it from next tick if any */
>  97         if (work->flags & IRQ_WORK_LAZY) {
>  98                 if (llist_add(&work->llnode, this_cpu_ptr(&lazy_list)) &&
>  99                     tick_nohz_tick_stopped())
> 100                         arch_irq_work_raise();
> 101         } else {
> 102                 if (llist_add(&work->llnode, this_cpu_ptr(&raised_list)))
> 103                         arch_irq_work_raise();
> 104         }
> …
> 109 }
> 
> so what I asked myself: What happens if the CPU is in NO_HZ mode with
> the tick off and you invoke arch_irq_work_raise() on an architecture
> without a special IRQ_WORK interrupt?

NO_HZ full can't run on such architecture. See the arch_irq_work_has_interrupt()
test on tick_nohz_init().

> And why you don't this tick_nohz_tick_stopped() check for the
> raised_list?

Because if the IRQ_WORK_LAZY flag isn't set, we want the interrupt to always
fire quickly. We don't want to wait for the next tick unless we have IRQ_WORK_LAZY.
Lazy works can wait a bit.

Now if the work is IRQ_WORK_LAZY and the tick is stopped, we need to trigger an
IPI because the next tick maybe too far ahead.

> Wouldn't it be a easier for your full NO_HZ code to simply run in the
> hardirq exit path instead of using irq_work?

Note only the tick wakeup happens from the IPI callback. The tick shutdown always
happens from irq exit.

But I'm working on doing the wakeup as well from irq exit.

I plan to piggyback on scheduler events instead of playing with IPIs, although
we'll still need them for perf and posix timers at least when those subsystems need
periodic tick.

> Sebastian
--
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/