On Mon, Oct 28, 2013 at 11:00 PM, Stephen Boyd <[email protected]> wrote: > On 10/28, Kevin Hilman wrote: >> Stephen Boyd <[email protected]> writes: >> >> > This will allow the scheduler tick to be restarted if we're in >> > full NOHZ mode. >> > >> > Cc: Kevin Hilman <[email protected]> >> > Cc: Frederic Weisbecker <[email protected]> >> > Signed-off-by: Stephen Boyd <[email protected]> >> >> Minor nit, but I'd prefer a more verbose changelog (I forget things >> quickly and like to rely on changelogs for my memory.) Probably worth >> adding something like: "By default, irq_work is tied to the tick >> processing (update_process_times()) but in full NOHZ mode, no tick means >> no IRQ work. In order for IRQ work to be done in full NOHZ mode, a >> self-IPI is used to process IRQ work." >> >> Other than the changelog nit, patch looks good, feel free to add >> >> Reviewed-by: Kevin Hilman <[email protected]> >> >> If Russell is OK with this, it can go to his patch system. >> > > Fair enough. This is what I came up with. I'll send it off to the > patch tracker in about 12 hours if nobody else has anymore > comments. > > ----8<----- > ARM: Support arch_irq_work_raise() via self IPIs > > By default, IRQ work is run from the tick interrupt (see > irq_work_run() in update_process_times()). When we're in full > NOHZ mode, restarting the tick requires the use of IRQ work and > if the only place we run IRQ work is in the tick interrupt we > have an unbreakable cycle. Implement arch_irq_work_raise() via > self IPIs to break this cycle and get the tick started again. > Note that we implement this via IPIs which are only available on > SMP builds. This shouldn't be a problem because full NOHZ is only > supported on SMP builds anyway. > > Signed-off-by: Stephen Boyd <[email protected]> > Reviewed-by: Kevin Hilman <[email protected]> > Cc: Frederic Weisbecker <[email protected]>
Hm, so I think this just landed in -next, which seems... late for 3.13. Anyway, it causes boot failures on Cubieboards (Allwinner A10), I just bisected it down to this patch (fails to boot multi_v7_defconfig, no console output at all). Unfortunately I'm not getting any debug_ll output from the board at the moment, so I can't actually get to a panic stack or other error info. :( I hope I can get back to you with one later today. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
