When a timer is enqueued or modified on a NO_HZ_FULL target (local or remote),
the target is expected to re-evaluate its timer wheel to decide if tick must be
restarted to handle timer expirations.
If it doesn't re-evaluate timer wheel and restart tick, it wouldn't be able to
call timer's handler on its expiration. It would be delayed until the time tick
is restarted again. Currently the max delay can be 1 second as returned by
scheduler_tick_max_deferment(), but it can increase in future.
To handle this, currently we are calling wake_up_nohz_cpu() from add_timer_on()
but what about timers enqueued/modified with other APIs?
For example, in __mod_timer() we get target cpu (where the timer should
get enqueued) by calling get_nohz_timer_target() and it is free to return a
NO_HZ_FULL cpu as well. So, we *should* re-evaluate timer wheel there as well,
otherwise call to timer's handler might be delayed as explained earlier.
In order to fix this issue we can move wake_up_nohz_cpu(cpu) to
internal_add_timer() so that it is well handled for any add-timer API.
LKML discussion about this: https://lkml.org/lkml/2014/6/4/169
This requires internal_add_timer() to get cpu number from per-cpu object 'base',
as all the callers might not have cpu number to pass to internal_add_timer().
For example, in __mod_timer() we find timer's base from 'timer' pointer and not
from per-cpu arithmetic.
Thus, this patch adds another field 'cpu' in 'struct tvec_base' which will store
cpu number of the cpu it belongs to.
Next patch will then move wake_up_nohz_cpu() to internal_add_timer().
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
kernel/timer.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/timer.c b/kernel/timer.c
index 3bb01a3..9e5f4f2 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -82,6 +82,7 @@ struct tvec_base {
unsigned long next_timer;
unsigned long active_timers;
unsigned long all_timers;
+ int cpu;
struct tvec_root tv1;
struct tvec tv2;
struct tvec tv3;
@@ -1568,6 +1569,7 @@ static int init_timers_cpu(int cpu)
}
spin_lock_init(&base->lock);
tvec_base_done[cpu] = 1;
+ base->cpu = cpu;
} else {
base = per_cpu(tvec_bases, cpu);
}
--
2.0.0.rc2
Hi Alexandru,
Here is the Linaro Kernel git repository list:
https://git.linaro.org/?a=project_list;pf=kernel
And which platform are you working on? Android or ubuntu? I ask because the
Kernel version on Android is the old one: 3.9.1
FYI.
On 5 June 2014 23:56, Alexandru Rosca <srosca(a)bu.edu> wrote:
> Hi Botao,
>
> The instructions online for building and deploying a linux kernel seems to
> be for version 3.1. I am using the latest arndale OS from the linaro
> releases and would like to know which source code you suggest I compile
> with the config file.
>
> Cheers,
> Alex
>
>
> On Thu, Jun 5, 2014 at 9:47 AM, Botao Sun <botao.sun(a)linaro.org> wrote:
>
>> + Linaro Kernel and Samsung Landing Team
>>
>> Hi Alexandru,
>>
>> As I know for the Linux mainline Kernel, we can run make menuconfig then
>> search the keyword by typing "/" and USB_SERIAL.
>>
>> Since we already have Linaro Samsung Arndale Kernel config file, then it
>> would be better to use this file and modify USB_SERIAL related items later:
>>
>> https://www.kernel.org/doc/index-old.html#Using_an_existing_configuration
>>
>> FYI.
>>
>> Thanks.
>>
>>
>> Best Regards
>> Botao Sun
>>
>>
>> On 5 June 2014 07:11, Alexandru Rosca <srosca(a)bu.edu> wrote:
>>
>>> Dear Botao Sun,
>>>
>>> I have an arndale board for which I would like to communicate with
>>> serially via an FTDI and some microcontrollers. It seems that the linaro
>>> kernel does not support this. I was thinking of compiling a kernel with the
>>> USB SERIAL config option set. Could you advise me on how to do this? Can I
>>> just use the config file for the arndale and modify it for compilation?
>>>
>>> Thank you,
>>> Sasha
>>>
>>
>>
>
+ Linaro Kernel and Samsung Landing Team
Hi Alexandru,
As I know for the Linux mainline Kernel, we can run make menuconfig then
search the keyword by typing "/" and USB_SERIAL.
Since we already have Linaro Samsung Arndale Kernel config file, then it
would be better to use this file and modify USB_SERIAL related items later:
https://www.kernel.org/doc/index-old.html#Using_an_existing_configuration
FYI.
Thanks.
Best Regards
Botao Sun
On 5 June 2014 07:11, Alexandru Rosca <srosca(a)bu.edu> wrote:
> Dear Botao Sun,
>
> I have an arndale board for which I would like to communicate with
> serially via an FTDI and some microcontrollers. It seems that the linaro
> kernel does not support this. I was thinking of compiling a kernel with the
> USB SERIAL config option set. Could you advise me on how to do this? Can I
> just use the config file for the arndale and modify it for compilation?
>
> Thank you,
> Sasha
>
From: Mark Brown <broonie(a)linaro.org>
Some of the generic drivers used on ARM class systems use OPP so allow it
to be selected in Kconfig. No code is required for this, it is not clear
to me why there is config for this option.
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
arch/arm64/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 8ccdd2646ae3..8256d6d09d33 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -2,6 +2,7 @@ config ARM64
def_bool y
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_USE_CMPXCHG_LOCKREF
+ select ARCH_HAS_OPP
select ARCH_HAS_SG_CHAIN
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_WANT_OPTIONAL_GPIOLIB
--
2.0.0.rc2
"Power" is a very bad term in the scheduler context. There are so many
meanings that can be attached to it. And with the upcoming "power
aware" scheduler work, confusion is sure to happen.
The definition of "power" is typically the rate at which work is performed,
energy is converted or electric energy is transferred. The notion of
"compute capacity" is rather at odds with "power" to the point many
comments in the code have to make it explicit that "capacity" is the
actual intended meaning.
So let's make it clear what we man by using "capacity" in place of "power"
directly in the code. That will make the introduction of actual "power
consumption" concepts much clearer later on.
This is based on the latest tip tree to apply correctly on top of existing
scheduler changes already queued there.
Changes from v1:
- capa_factor and SCHED_CAPA_* changed to be spelled "capacity" in full
to save peterz some Chupacabra nightmares
- some minor corrections in commit logs
- rebased on latest tip tree
arch/arm/kernel/topology.c | 54 +++----
include/linux/sched.h | 8 +-
kernel/sched/core.c | 87 ++++++-----
kernel/sched/fair.c | 323 ++++++++++++++++++++-------------------
kernel/sched/sched.h | 18 +--
5 files changed, 246 insertions(+), 244 deletions(-)
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Viresh Kumar <viresh.kumar(a)linaro.org>
commit 84ea7fe37908254c3bd90910921f6e1045c1747a upstream.
switch_hrtimer_base() calls hrtimer_check_target() which ensures that
we do not migrate a timer to a remote cpu if the timer expires before
the current programmed expiry time on that remote cpu.
But __hrtimer_start_range_ns() calls switch_hrtimer_base() before the
new expiry time is set. So the sanity check in hrtimer_check_target()
is operating on stale or even uninitialized data.
Update expiry time before calling switch_hrtimer_base().
[ tglx: Rewrote changelog once again ]
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
Cc: linaro-kernel(a)lists.linaro.org
Cc: linaro-networking(a)linaro.org
Cc: fweisbec(a)gmail.com
Cc: arvind.chauhan(a)arm.com
Link: http://lkml.kernel.org/r/81999e148745fc51bbcd0615823fbab9b2e87e23.139988225…
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/hrtimer.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -985,11 +985,8 @@ int __hrtimer_start_range_ns(struct hrti
/* Remove an active timer from the queue: */
ret = remove_hrtimer(timer, base);
- /* Switch the timer base, if necessary: */
- new_base = switch_hrtimer_base(timer, base, mode & HRTIMER_MODE_PINNED);
-
if (mode & HRTIMER_MODE_REL) {
- tim = ktime_add_safe(tim, new_base->get_time());
+ tim = ktime_add_safe(tim, base->get_time());
/*
* CONFIG_TIME_LOW_RES is a temporary way for architectures
* to signal that they simply return xtime in
@@ -1004,6 +1001,9 @@ int __hrtimer_start_range_ns(struct hrti
hrtimer_set_expires_range_ns(timer, tim, delta_ns);
+ /* Switch the timer base, if necessary: */
+ new_base = switch_hrtimer_base(timer, base, mode & HRTIMER_MODE_PINNED);
+
timer_stats_hrtimer_set_start_info(timer);
leftmost = enqueue_hrtimer(timer, new_base);
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Viresh Kumar <viresh.kumar(a)linaro.org>
commit 84ea7fe37908254c3bd90910921f6e1045c1747a upstream.
switch_hrtimer_base() calls hrtimer_check_target() which ensures that
we do not migrate a timer to a remote cpu if the timer expires before
the current programmed expiry time on that remote cpu.
But __hrtimer_start_range_ns() calls switch_hrtimer_base() before the
new expiry time is set. So the sanity check in hrtimer_check_target()
is operating on stale or even uninitialized data.
Update expiry time before calling switch_hrtimer_base().
[ tglx: Rewrote changelog once again ]
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
Cc: linaro-kernel(a)lists.linaro.org
Cc: linaro-networking(a)linaro.org
Cc: fweisbec(a)gmail.com
Cc: arvind.chauhan(a)arm.com
Link: http://lkml.kernel.org/r/81999e148745fc51bbcd0615823fbab9b2e87e23.139988225…
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/hrtimer.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -999,11 +999,8 @@ int __hrtimer_start_range_ns(struct hrti
/* Remove an active timer from the queue: */
ret = remove_hrtimer(timer, base);
- /* Switch the timer base, if necessary: */
- new_base = switch_hrtimer_base(timer, base, mode & HRTIMER_MODE_PINNED);
-
if (mode & HRTIMER_MODE_REL) {
- tim = ktime_add_safe(tim, new_base->get_time());
+ tim = ktime_add_safe(tim, base->get_time());
/*
* CONFIG_TIME_LOW_RES is a temporary way for architectures
* to signal that they simply return xtime in
@@ -1018,6 +1015,9 @@ int __hrtimer_start_range_ns(struct hrti
hrtimer_set_expires_range_ns(timer, tim, delta_ns);
+ /* Switch the timer base, if necessary: */
+ new_base = switch_hrtimer_base(timer, base, mode & HRTIMER_MODE_PINNED);
+
timer_stats_hrtimer_set_start_info(timer);
leftmost = enqueue_hrtimer(timer, new_base);
3.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Viresh Kumar <viresh.kumar(a)linaro.org>
commit 84ea7fe37908254c3bd90910921f6e1045c1747a upstream.
switch_hrtimer_base() calls hrtimer_check_target() which ensures that
we do not migrate a timer to a remote cpu if the timer expires before
the current programmed expiry time on that remote cpu.
But __hrtimer_start_range_ns() calls switch_hrtimer_base() before the
new expiry time is set. So the sanity check in hrtimer_check_target()
is operating on stale or even uninitialized data.
Update expiry time before calling switch_hrtimer_base().
[ tglx: Rewrote changelog once again ]
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
Cc: linaro-kernel(a)lists.linaro.org
Cc: linaro-networking(a)linaro.org
Cc: fweisbec(a)gmail.com
Cc: arvind.chauhan(a)arm.com
Link: http://lkml.kernel.org/r/81999e148745fc51bbcd0615823fbab9b2e87e23.139988225…
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/hrtimer.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -1003,11 +1003,8 @@ int __hrtimer_start_range_ns(struct hrti
/* Remove an active timer from the queue: */
ret = remove_hrtimer(timer, base);
- /* Switch the timer base, if necessary: */
- new_base = switch_hrtimer_base(timer, base, mode & HRTIMER_MODE_PINNED);
-
if (mode & HRTIMER_MODE_REL) {
- tim = ktime_add_safe(tim, new_base->get_time());
+ tim = ktime_add_safe(tim, base->get_time());
/*
* CONFIG_TIME_LOW_RES is a temporary way for architectures
* to signal that they simply return xtime in
@@ -1022,6 +1019,9 @@ int __hrtimer_start_range_ns(struct hrti
hrtimer_set_expires_range_ns(timer, tim, delta_ns);
+ /* Switch the timer base, if necessary: */
+ new_base = switch_hrtimer_base(timer, base, mode & HRTIMER_MODE_PINNED);
+
timer_stats_hrtimer_set_start_info(timer);
leftmost = enqueue_hrtimer(timer, new_base);