All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: john.stultz@linaro.org, viresh.kumar@linaro.org,
	jacob.jun.pan@linux.intel.com,
	linux-arm-kernel@lists.infradead.org, santosh.shilimkar@ti.com,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
	linaro-kernel@lists.linaro.org, patches@linaro.org,
	rickard.andersson@stericsson.com, vincent.guittot@linaro.org,
	linus.walleij@stericsson.com
Subject: Re: [PATCH 2/4][V2] time : set broadcast irq affinity
Date: Wed, 06 Mar 2013 10:27:37 +0100	[thread overview]
Message-ID: <51370C09.5020301@linaro.org> (raw)
In-Reply-To: <alpine.LFD.2.02.1303052135080.22263@ionos>

On 03/05/2013 09:40 PM, Thomas Gleixner wrote:
> On Sat, 2 Mar 2013, Daniel Lezcano wrote:
>> When a cpu goes to a deep idle state where its local timer is shutdown,
>> it notifies the time frame work to use the broadcast timer instead.
>>
>> Unfortunately, the broadcast device could wake up any CPU, including an
>> idle one which is not concerned by the wake up at all.
>>
>> This implies, in the worst case, an idle CPU will wake up to send an IPI
>> to another idle cpu.
>>
>> This patch solves this by setting the irq affinity to the cpu concerned
>> by the nearest timer event, by this way, the CPU which is wake up is
>> guarantee to be the one concerned by the next event and we are safe with
>> unnecessary wakeup for another idle CPU.
>>
>> As the irq affinity is not supported by all the archs, a flag is needed
>> to specify which clocksource can handle it : CLOCK_EVT_FEAT_DYNIRQ
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>> ---
>>  include/linux/clockchips.h   |    5 +++++
>>  kernel/time/tick-broadcast.c |   40 +++++++++++++++++++++++++++++++++-------
>>  2 files changed, 38 insertions(+), 7 deletions(-)
>>
>> diff --git a/include/linux/clockchips.h b/include/linux/clockchips.h
>> index 6634652..c93e2a6 100644
>> --- a/include/linux/clockchips.h
>> +++ b/include/linux/clockchips.h
>> @@ -55,6 +55,11 @@ enum clock_event_nofitiers {
>>  #define CLOCK_EVT_FEAT_C3STOP		0x000008
>>  #define CLOCK_EVT_FEAT_DUMMY		0x000010
>>  
>> +/*
>> + * Clock event device can set its irq affinity dynamically
>> + */
>> +#define CLOCK_EVT_FEAT_DYNIRQ		0x000020
>> +
>>  /**
>>   * struct clock_event_device - clock event device descriptor
>>   * @event_handler:	Assigned by the framework to be called by the low
>> diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
>> index 6197ac0..9ca8ff5 100644
>> --- a/kernel/time/tick-broadcast.c
>> +++ b/kernel/time/tick-broadcast.c
>> @@ -406,13 +406,37 @@ struct cpumask *tick_get_broadcast_oneshot_mask(void)
>>  	return to_cpumask(tick_broadcast_oneshot_mask);
>>  }
>>  
>> -static int tick_broadcast_set_event(struct clock_event_device *bc,
>> +/*
>> + * Set broadcast interrupt affinity
>> + */
>> +static void tick_broadcast_set_affinity(struct clock_event_device *bc,
>> +					const struct cpumask *cpumask)
>> +{
>> +	if (!(bc->features & CLOCK_EVT_FEAT_DYNIRQ))
>> +		return;
>> +
>> +	if (cpumask_equal(bc->cpumask, cpumask))
>> +		return;
>> +
>> +	bc->cpumask = cpumask;
> 
> This breaks with CONFIG_CPUMASK_OFFSTACK=y. cpumask_copy() is your friend!

This instruction copies the pointer, not the cpumask content.

bc->cpumask is defined as a const struct cpumask * and is used to copy a
cpumask pointer not the content.

The cpumask parameter is a pointer to a global cpumask provided by the
cpumask_of macro.

But to be in the safe side, I compiled tested with
CONFIG_CPUMASK_OFFSTACK=y without problem.

Did I missed something ?

Thanks
  -- Daniel

> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog


WARNING: multiple messages have this Message-ID (diff)
From: daniel.lezcano@linaro.org (Daniel Lezcano)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/4][V2] time : set broadcast irq affinity
Date: Wed, 06 Mar 2013 10:27:37 +0100	[thread overview]
Message-ID: <51370C09.5020301@linaro.org> (raw)
In-Reply-To: <alpine.LFD.2.02.1303052135080.22263@ionos>

On 03/05/2013 09:40 PM, Thomas Gleixner wrote:
> On Sat, 2 Mar 2013, Daniel Lezcano wrote:
>> When a cpu goes to a deep idle state where its local timer is shutdown,
>> it notifies the time frame work to use the broadcast timer instead.
>>
>> Unfortunately, the broadcast device could wake up any CPU, including an
>> idle one which is not concerned by the wake up at all.
>>
>> This implies, in the worst case, an idle CPU will wake up to send an IPI
>> to another idle cpu.
>>
>> This patch solves this by setting the irq affinity to the cpu concerned
>> by the nearest timer event, by this way, the CPU which is wake up is
>> guarantee to be the one concerned by the next event and we are safe with
>> unnecessary wakeup for another idle CPU.
>>
>> As the irq affinity is not supported by all the archs, a flag is needed
>> to specify which clocksource can handle it : CLOCK_EVT_FEAT_DYNIRQ
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>> ---
>>  include/linux/clockchips.h   |    5 +++++
>>  kernel/time/tick-broadcast.c |   40 +++++++++++++++++++++++++++++++++-------
>>  2 files changed, 38 insertions(+), 7 deletions(-)
>>
>> diff --git a/include/linux/clockchips.h b/include/linux/clockchips.h
>> index 6634652..c93e2a6 100644
>> --- a/include/linux/clockchips.h
>> +++ b/include/linux/clockchips.h
>> @@ -55,6 +55,11 @@ enum clock_event_nofitiers {
>>  #define CLOCK_EVT_FEAT_C3STOP		0x000008
>>  #define CLOCK_EVT_FEAT_DUMMY		0x000010
>>  
>> +/*
>> + * Clock event device can set its irq affinity dynamically
>> + */
>> +#define CLOCK_EVT_FEAT_DYNIRQ		0x000020
>> +
>>  /**
>>   * struct clock_event_device - clock event device descriptor
>>   * @event_handler:	Assigned by the framework to be called by the low
>> diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
>> index 6197ac0..9ca8ff5 100644
>> --- a/kernel/time/tick-broadcast.c
>> +++ b/kernel/time/tick-broadcast.c
>> @@ -406,13 +406,37 @@ struct cpumask *tick_get_broadcast_oneshot_mask(void)
>>  	return to_cpumask(tick_broadcast_oneshot_mask);
>>  }
>>  
>> -static int tick_broadcast_set_event(struct clock_event_device *bc,
>> +/*
>> + * Set broadcast interrupt affinity
>> + */
>> +static void tick_broadcast_set_affinity(struct clock_event_device *bc,
>> +					const struct cpumask *cpumask)
>> +{
>> +	if (!(bc->features & CLOCK_EVT_FEAT_DYNIRQ))
>> +		return;
>> +
>> +	if (cpumask_equal(bc->cpumask, cpumask))
>> +		return;
>> +
>> +	bc->cpumask = cpumask;
> 
> This breaks with CONFIG_CPUMASK_OFFSTACK=y. cpumask_copy() is your friend!

This instruction copies the pointer, not the cpumask content.

bc->cpumask is defined as a const struct cpumask * and is used to copy a
cpumask pointer not the content.

The cpumask parameter is a pointer to a global cpumask provided by the
cpumask_of macro.

But to be in the safe side, I compiled tested with
CONFIG_CPUMASK_OFFSTACK=y without problem.

Did I missed something ?

Thanks
  -- Daniel

> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

  reply	other threads:[~2013-03-06  9:27 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-02 10:10 [PATCH 0/4][V2] time: dynamic irq affinity Daniel Lezcano
2013-03-02 10:10 ` Daniel Lezcano
2013-03-02 10:10 ` [PATCH 1/4][V2] time : pass broadcast parameter Daniel Lezcano
2013-03-02 10:10   ` Daniel Lezcano
2013-03-02 10:10   ` Daniel Lezcano
2013-03-07 16:31   ` [tip:timers/core] tick: Pass broadcast device to tick_broadcast_set_event() tip-bot for Daniel Lezcano
2013-03-02 10:10 ` [PATCH 2/4][V2] time : set broadcast irq affinity Daniel Lezcano
2013-03-02 10:10   ` Daniel Lezcano
2013-03-05 20:40   ` Thomas Gleixner
2013-03-05 20:40     ` Thomas Gleixner
2013-03-06  9:27     ` Daniel Lezcano [this message]
2013-03-06  9:27       ` Daniel Lezcano
2013-03-06  9:48       ` Thomas Gleixner
2013-03-06  9:48         ` Thomas Gleixner
2013-03-06 12:35         ` Daniel Lezcano
2013-03-06 12:35           ` Daniel Lezcano
2013-03-08  4:38         ` Daniel Lezcano
2013-03-08  4:38           ` Daniel Lezcano
2013-03-08  7:20           ` Thomas Gleixner
2013-03-08  7:20             ` Thomas Gleixner
2013-03-11 21:00             ` Arnd Bergmann
2013-03-11 21:00               ` Arnd Bergmann
2013-03-07 16:33   ` [tip:timers/core] tick: Dynamically " tip-bot for Daniel Lezcano
2013-03-02 10:10 ` [PATCH 3/4][V2] ARM: nomadik: add dynamic irq flag to the timer Daniel Lezcano
2013-03-02 10:10   ` Daniel Lezcano
2013-03-02 10:10 ` [PATCH 4/4][V2] ARM: timer-sp: Set dynamic irq affinity Daniel Lezcano
2013-03-02 10:10   ` Daniel Lezcano
2013-03-08 15:28   ` Daniel Lezcano
2013-03-08 15:28     ` Daniel Lezcano
2013-03-11 16:22     ` Russell King - ARM Linux
2013-03-11 16:22       ` Russell King - ARM Linux
2013-03-08 15:17 ` [PATCH 3/4][V2] ARM: nomadik: add dynamic irq flag to the timer Daniel Lezcano
2013-03-08 15:17   ` Daniel Lezcano
2013-03-08 16:03   ` Thomas Gleixner
2013-03-08 16:03     ` Thomas Gleixner
2013-03-19 11:42     ` Daniel Lezcano
2013-03-19 11:42       ` Daniel Lezcano
2013-03-12 11:38   ` Linus Walleij
2013-03-12 11:38     ` Linus Walleij

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51370C09.5020301@linaro.org \
    --to=daniel.lezcano@linaro.org \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=john.stultz@linaro.org \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linus.walleij@stericsson.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=patches@linaro.org \
    --cc=rickard.andersson@stericsson.com \
    --cc=santosh.shilimkar@ti.com \
    --cc=tglx@linutronix.de \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.