From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754529AbbCIPJ6 (ORCPT ); Mon, 9 Mar 2015 11:09:58 -0400 Received: from mail-we0-f180.google.com ([74.125.82.180]:35140 "EHLO mail-we0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751738AbbCIPJ4 (ORCPT ); Mon, 9 Mar 2015 11:09:56 -0400 Date: Mon, 9 Mar 2015 16:09:51 +0100 From: Frederic Weisbecker To: Sebastian Andrzej Siewior Cc: linux-kernel@vger.kernel.org Subject: Re: full no_hz: how works arch_irq_work_raise() with tick off on generic implementation Message-ID: <20150309150949.GB25605@lerouge> References: <20150309140917.GB13768@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150309140917.GB13768@linutronix.de> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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