Re: [tip:timers/core] ARM: Kconfig: allow full nohz CPU accounting

[Frederic Weisbecker]

2013/10/18 Stephen Boyd <sboyd@xxxxxxxxxxxxxx>:
> On 10/16, Frederic Weisbecker wrote:
>> On Thu, Oct 03, 2013 at 06:58:03AM -0700, tip-bot for Kevin Hilman wrote:
>> > Commit-ID:  31c1fc8187158cb80ccd57c19e024c55af901797
>> > Gitweb:     http://git.kernel.org/tip/31c1fc8187158cb80ccd57c19e024c55af901797
>> > Author:     Kevin Hilman <khilman@xxxxxxxxxx>
>> > AuthorDate: Mon, 16 Sep 2013 15:28:22 -0700
>> > Committer:  Frederic Weisbecker <fweisbec@xxxxxxxxx>
>> > CommitDate: Mon, 30 Sep 2013 15:37:05 +0200
>> >
>> > ARM: Kconfig: allow full nohz CPU accounting
>> >
>> > With the 64-bit requirement removed from VIRT_CPU_ACCOUNTING_GEN,
>> > allow ARM platforms to enable it.  Since VIRT_CPU_ACCOUNTING_GEN is a
>> > dependency for full NO_HZ, this allows ARM platforms to enable full
>> > NO_HZ as well.
>>
>> I realize that arm doesn't implement irq work raise. It hooks on the
>> timer to execute pending irq work. You'll need to implement arch_irq_work_raise()
>> and implement some sort of self IPI to trigger irq work. The full dynticks subsystem
>> relies on that to work correctly. It often use that to re-evaluate and possibly restart
>> the tick after scheduler, posix timer updates, etc...
>>
>> That notwithstanding that if you have no tick, tick based irq work can't
>> work.
>>
>
> Something like this? The only problem is that this latches on to
> the SMP support for IPIs. If CONFIG_SMP is disabled we won't get
> arch_irq_work_raise() but perhaps that isn't so big of a deal? Or
> we should think about exposing IPI support to UP systems on ARM.
>
> ----8<-----
>  arch/arm/include/asm/hardirq.h |  2 +-
>  arch/arm/kernel/smp.c          | 18 ++++++++++++++++++
>  2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/hardirq.h b/arch/arm/include/asm/hardirq.h
> index 2740c2a2..3d7351c 100644
> --- a/arch/arm/include/asm/hardirq.h
> +++ b/arch/arm/include/asm/hardirq.h
> @@ -5,7 +5,7 @@
>  #include <linux/threads.h>
>  #include <asm/irq.h>
>
> -#define NR_IPI 6
> +#define NR_IPI 7
>
>  typedef struct {
>         unsigned int __softirq_pending;
> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> index 72024ea..bf9a0d6d 100644
> --- a/arch/arm/kernel/smp.c
> +++ b/arch/arm/kernel/smp.c
> @@ -25,6 +25,7 @@
>  #include <linux/clockchips.h>
>  #include <linux/completion.h>
>  #include <linux/cpufreq.h>
> +#include <linux/irq_work.h>
>
>  #include <linux/atomic.h>
>  #include <asm/smp.h>
> @@ -66,6 +67,7 @@ enum ipi_msg_type {
>         IPI_CALL_FUNC,
>         IPI_CALL_FUNC_SINGLE,
>         IPI_CPU_STOP,
> +       IPI_IRQ_WORK,
>  };
>
>  static DECLARE_COMPLETION(cpu_running);
> @@ -448,6 +450,13 @@ void arch_send_call_function_single_ipi(int cpu)
>         smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE);
>  }
>
> +#ifdef CONFIG_IRQ_WORK
> +void arch_irq_work_raise(void)
> +{
> +       smp_cross_call(cpumask_of(smp_processor_id()), IPI_IRQ_WORK);
> +}
> +#endif
> +
>  static const char *ipi_types[NR_IPI] = {
>  #define S(x,s) [x] = s
>         S(IPI_WAKEUP, "CPU wakeup interrupts"),
> @@ -456,6 +465,7 @@ static const char *ipi_types[NR_IPI] = {
>         S(IPI_CALL_FUNC, "Function call interrupts"),
>         S(IPI_CALL_FUNC_SINGLE, "Single function call interrupts"),
>         S(IPI_CPU_STOP, "CPU stop interrupts"),
> +       S(IPI_IRQ_WORK, "IRQ work interrupts"),
>  };
>
>  void show_ipi_list(struct seq_file *p, int prec)
> @@ -565,6 +575,14 @@ void handle_IPI(int ipinr, struct pt_regs *regs)
>                 irq_exit();
>                 break;
>
> +#ifdef CONFIG_IRQ_WORK
> +       case IPI_IRQ_WORK:
> +               irq_enter();
> +               irq_work_run();
> +               irq_exit();
> +               break;
> +#endif
> +
>         default:
>                 printk(KERN_CRIT "CPU%u: Unknown IPI message 0x%x\n",
>                        cpu, ipinr);

Yeah that looks good! Indeed it's no big deal if it only support SMP
for now since full dynticks only works on SMP. It might work on UP one
day but we are not yet rushing on that :)
--
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/