Re: [PATCH] ARM: Support arch_irq_work_raise() via self IPIs
From: Stephen Boyd
Date: Tue Oct 29 2013 - 02:01:23 EST
On 10/28, Kevin Hilman wrote:
> Stephen Boyd <sboyd@xxxxxxxxxxxxxx> writes:
> > This will allow the scheduler tick to be restarted if we're in
> > full NOHZ mode.
> > Cc: Kevin Hilman <khilman@xxxxxxxxxx>
> > Cc: Frederic Weisbecker <fweisbec@xxxxxxxxx>
> > Signed-off-by: Stephen Boyd <sboyd@xxxxxxxxxxxxxx>
> 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 <khilman@xxxxxxxxxx>
> 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
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 <sboyd@xxxxxxxxxxxxxx>
Reviewed-by: Kevin Hilman <khilman@xxxxxxxxxx>
Cc: Frederic Weisbecker <fweisbec@xxxxxxxxx>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/