Commit-ID: 5c7e11bc66647f2e4bc95de9b4302fff6d612f3a
Gitweb: http://git.kernel.org/tip/5c7e11bc66647f2e4bc95de9b4302fff6d612f3a
Author: Xunlei Pang pang.xun...@linaro.org
AuthorDate: Wed, 1 Apr 2015 20:34:29 -0700
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Fri, 3 Apr 2015 08:18
Commit-ID: 8e4ff1a81aa91d12856287c7103d0301ac91351a
Gitweb: http://git.kernel.org/tip/8e4ff1a81aa91d12856287c7103d0301ac91351a
Author: Xunlei Pang pang.xun...@linaro.org
AuthorDate: Wed, 1 Apr 2015 20:34:27 -0700
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Fri, 3 Apr 2015 08:18
Commit-ID: 4d644ab84c6ed66f7a628c74d83c34d85bec13bf
Gitweb: http://git.kernel.org/tip/4d644ab84c6ed66f7a628c74d83c34d85bec13bf
Author: Xunlei Pang pang.xun...@linaro.org
AuthorDate: Wed, 1 Apr 2015 20:34:28 -0700
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Fri, 3 Apr 2015 08:18
Commit-ID: 3c00a1fe8496ff29ab62764bb3f4ce4b48089004
Gitweb: http://git.kernel.org/tip/3c00a1fe8496ff29ab62764bb3f4ce4b48089004
Author: Xunlei Pang pang.xun...@linaro.org
AuthorDate: Wed, 1 Apr 2015 20:34:23 -0700
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Fri, 3 Apr 2015 08:18
Commit-ID: 0307b0d77a0830b0fd4a22b5db4a9fa723a5fa5f
Gitweb: http://git.kernel.org/tip/0307b0d77a0830b0fd4a22b5db4a9fa723a5fa5f
Author: Xunlei Pang pang.xun...@linaro.org
AuthorDate: Wed, 1 Apr 2015 20:34:30 -0700
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Fri, 3 Apr 2015 08:18
Commit-ID: 482494a8d395877c4776a3d76f89342d7ad7c4c6
Gitweb: http://git.kernel.org/tip/482494a8d395877c4776a3d76f89342d7ad7c4c6
Author: Xunlei Pang pang.xun...@linaro.org
AuthorDate: Wed, 1 Apr 2015 20:34:31 -0700
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Fri, 3 Apr 2015 08:18
Commit-ID: a0c2998f918e7e597d3c686c5f3d5a30d0382dd6
Gitweb: http://git.kernel.org/tip/a0c2998f918e7e597d3c686c5f3d5a30d0382dd6
Author: Xunlei Pang pang.xun...@linaro.org
AuthorDate: Wed, 1 Apr 2015 20:34:25 -0700
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Fri, 3 Apr 2015 08:18
Commit-ID: a451570c008b9e19592e29f15cfd295bdf818c7a
Gitweb: http://git.kernel.org/tip/a451570c008b9e19592e29f15cfd295bdf818c7a
Author: Xunlei Pang pang.xun...@linaro.org
AuthorDate: Wed, 1 Apr 2015 20:34:24 -0700
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Fri, 3 Apr 2015 08:18
Commit-ID: 2ee966320028ac846654eba5344540eeb4dc228d
Gitweb: http://git.kernel.org/tip/2ee966320028ac846654eba5344540eeb4dc228d
Author: Xunlei Pang pang.xun...@linaro.org
AuthorDate: Wed, 1 Apr 2015 20:34:22 -0700
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Fri, 3 Apr 2015 08:18
Hi Vincent,
On 1 April 2015 at 17:06, Vincent Guittot wrote:
> On 1 April 2015 at 05:37, Xunlei Pang wrote:
>> Hi Vincent,
>>
>> On 27 March 2015 at 23:59, Vincent Guittot
>> wrote:
>>> On 27 March 2015 at 15:52, Xunlei Pang wrote:
>>>> Hi
Hi Vincent,
On 1 April 2015 at 17:06, Vincent Guittot vincent.guit...@linaro.org wrote:
On 1 April 2015 at 05:37, Xunlei Pang pang.xun...@linaro.org wrote:
Hi Vincent,
On 27 March 2015 at 23:59, Vincent Guittot vincent.guit...@linaro.org
wrote:
On 27 March 2015 at 15:52, Xunlei Pang
Hi Vincent,
On 27 March 2015 at 23:59, Vincent Guittot wrote:
> On 27 March 2015 at 15:52, Xunlei Pang wrote:
>> Hi Vincent,
>>
>> On 27 February 2015 at 23:54, Vincent Guittot
>> wrote:
>>> /**
>>> @@ -6432,18 +6435,19 @@ static inline void updat
Vincent,
On 27 March 2015 at 23:37, Vincent Guittot wrote:
> On 27 March 2015 at 16:12, Xunlei Pang wrote:
>>> +static int get_cpu_usage(int cpu)
>>> +{
>>> + unsigned long usage = cpu_rq(cpu)->cfs.utilization_load_avg;
>>> + uns
On 27 March 2015 at 23:30, Peter Zijlstra wrote:
> On Wed, Mar 18, 2015 at 02:31:02PM +0800, Xunlei Pang wrote:
>> From: Xunlei Pang
>>
>> In load_balance(), some members of lb_env will be assigned with
>> new values in LBF_DST_PINNED case. But lb_env::flags may sti
On 27 March 2015 at 23:28, Steven Rostedt wrote:
> On Mon, 9 Mar 2015 15:32:27 +0800
> Xunlei Pang wrote:
>
>> From: Xunlei Pang
>>
>> Currently, SMP RT scheduler has some trouble in dealing with
>> equal prio cases.
>>
>> For example, in check_p
On 27 March 2015 at 23:30, Peter Zijlstra pet...@infradead.org wrote:
On Wed, Mar 18, 2015 at 02:31:02PM +0800, Xunlei Pang wrote:
From: Xunlei Pang pang.xun...@linaro.org
In load_balance(), some members of lb_env will be assigned with
new values in LBF_DST_PINNED case. But lb_env::flags may
On 27 March 2015 at 23:28, Steven Rostedt rost...@goodmis.org wrote:
On Mon, 9 Mar 2015 15:32:27 +0800
Xunlei Pang xlp...@126.com wrote:
From: Xunlei Pang pang.xun...@linaro.org
Currently, SMP RT scheduler has some trouble in dealing with
equal prio cases.
For example
Vincent,
On 27 March 2015 at 23:37, Vincent Guittot vincent.guit...@linaro.org wrote:
On 27 March 2015 at 16:12, Xunlei Pang pang.xun...@linaro.org wrote:
+static int get_cpu_usage(int cpu)
+{
+ unsigned long usage = cpu_rq(cpu)-cfs.utilization_load_avg;
+ unsigned long capacity
Hi Vincent,
On 27 March 2015 at 23:59, Vincent Guittot vincent.guit...@linaro.org wrote:
On 27 March 2015 at 15:52, Xunlei Pang pang.xun...@linaro.org wrote:
Hi Vincent,
On 27 February 2015 at 23:54, Vincent Guittot
vincent.guit...@linaro.org wrote:
/**
@@ -6432,18 +6435,19 @@ static
Hi Vincent,
On 27 February 2015 at 23:54, Vincent Guittot
wrote:
> Monitor the usage level of each group of each sched_domain level. The usage is
> the portion of cpu_capacity_orig that is currently used on a CPU or group of
> CPUs. We use the utilization_load_avg to evaluate the usage level of
Hi Vincent,
On 27 February 2015 at 23:54, Vincent Guittot
wrote:
> /**
> @@ -6432,18 +6435,19 @@ static inline void update_sd_lb_stats(struct lb_env
> *env, struct sd_lb_stats *sd
>
> /*
> * In case the child domain prefers tasks go to siblings
> -
Ping Steve
> From: Xunlei Pang
>
> Currently, SMP RT scheduler has some trouble in dealing with
> equal prio cases.
>
> For example, in check_preempt_equal_prio():
> When RT1(current task) gets preempted by RT2, if there is a
> migratable RT3 with same prio, RT3 wil
Ping Juri
> From: Xunlei Pang
>
> In check_preempt_equal_dl(), cpudl_find() is called with a NULL
> later_mask, thus cpudl_find() here doesn't check cpudl::free_cpus
> at all.
>
> This patch takles this issue by always passing a non-NULL later_mask
> to cpudl_find(), t
Ping Peter
> From: Xunlei Pang
>
> In load_balance(), some members of lb_env will be assigned with
> new values in LBF_DST_PINNED case. But lb_env::flags may still
> retain LBF_ALL_PINNED if no proper tasks were found afterwards
> due to another balance, task affinity changi
Ping Peter
From: Xunlei Pang pang.xun...@linaro.org
In load_balance(), some members of lb_env will be assigned with
new values in LBF_DST_PINNED case. But lb_env::flags may still
retain LBF_ALL_PINNED if no proper tasks were found afterwards
due to another balance, task affinity changing
Ping Steve
From: Xunlei Pang pang.xun...@linaro.org
Currently, SMP RT scheduler has some trouble in dealing with
equal prio cases.
For example, in check_preempt_equal_prio():
When RT1(current task) gets preempted by RT2, if there is a
migratable RT3 with same prio, RT3 will be pushed away
Ping Juri
From: Xunlei Pang pang.xun...@linaro.org
In check_preempt_equal_dl(), cpudl_find() is called with a NULL
later_mask, thus cpudl_find() here doesn't check cpudl::free_cpus
at all.
This patch takles this issue by always passing a non-NULL later_mask
to cpudl_find(), thereby fixing
Hi Vincent,
On 27 February 2015 at 23:54, Vincent Guittot
vincent.guit...@linaro.org wrote:
/**
@@ -6432,18 +6435,19 @@ static inline void update_sd_lb_stats(struct lb_env
*env, struct sd_lb_stats *sd
/*
* In case the child domain prefers tasks go to
Hi Vincent,
On 27 February 2015 at 23:54, Vincent Guittot
vincent.guit...@linaro.org wrote:
Monitor the usage level of each group of each sched_domain level. The usage is
the portion of cpu_capacity_orig that is currently used on a CPU or group of
CPUs. We use the utilization_load_avg to
From: Xunlei Pang
When there's no persistent clock, normally timekeeping_suspend_time
should always be zero, but this can break in timekeeping_suspend().
At T1, there was a system suspend, so old_delta was assigned T1.
After some time, one time adjustment happened, and xtime got the
value of T1
From: Xunlei Pang
If a system does not provide a persistent_clock(), the time
will be updated on resume by rtc_resume(). With the addition
of the non-stop clocksources for suspend timing, those systems
set the time on resume in timekeeping_resume(), but may not
provide a valid persistent_clock
From: Xunlei Pang
Currently, RT global scheduling doesn't factor deadline
tasks, this may cause some problems.
See a case below:
On a 3 CPU system, CPU0 has one running deadline task,
CPU1 has one running low priority RT task or idle, CPU3
has one running high priority RT task. When another mid
From: Xunlei Pang
In check_preempt_equal_dl(), cpudl_find() is called with a NULL
later_mask, thus cpudl_find() here doesn't check cpudl::free_cpus
at all.
This patch takles this issue by always passing a non-NULL later_mask
to cpudl_find(), thereby fixing this issue.
Signed-off-by: Xunlei
From: Xunlei Pang
In load_balance(), some members of lb_env will be assigned with
new values in LBF_DST_PINNED case. But lb_env::flags may still
retain LBF_ALL_PINNED if no proper tasks were found afterwards
due to another balance, task affinity changing, etc, which can
really happen because
From: Xunlei Pang pang.xun...@linaro.org
In check_preempt_equal_dl(), cpudl_find() is called with a NULL
later_mask, thus cpudl_find() here doesn't check cpudl::free_cpus
at all.
This patch takles this issue by always passing a non-NULL later_mask
to cpudl_find(), thereby fixing this issue
From: Xunlei Pang pang.xun...@linaro.org
Currently, RT global scheduling doesn't factor deadline
tasks, this may cause some problems.
See a case below:
On a 3 CPU system, CPU0 has one running deadline task,
CPU1 has one running low priority RT task or idle, CPU3
has one running high priority RT
From: Xunlei Pang pang.xun...@linaro.org
In load_balance(), some members of lb_env will be assigned with
new values in LBF_DST_PINNED case. But lb_env::flags may still
retain LBF_ALL_PINNED if no proper tasks were found afterwards
due to another balance, task affinity changing, etc, which can
From: Xunlei Pang pang.xun...@linaro.org
If a system does not provide a persistent_clock(), the time
will be updated on resume by rtc_resume(). With the addition
of the non-stop clocksources for suspend timing, those systems
set the time on resume in timekeeping_resume(), but may not
provide
From: Xunlei Pang pang.xun...@linaro.org
When there's no persistent clock, normally timekeeping_suspend_time
should always be zero, but this can break in timekeeping_suspend().
At T1, there was a system suspend, so old_delta was assigned T1.
After some time, one time adjustment happened
From: Xunlei Pang
As part of addressing "y2038 problem" for in-kernel uses, this
patch converts read_boot_clock() to read_boot_clock64() and
read_persistent_clock() to read_persistent_clock64() using
timespec64 by converting clock_access_fn to use timespec64.
Signed-off-by: X
From: Xunlei Pang
As part of addressing "y2038 problem" for in-kernel uses, this
patch converts read_boot_clock() to read_boot_clock64() and
read_persistent_clock() to read_persistent_clock64() using
timespec64.
Since S390 is a 64bit architecture, also rename some timespec
to
From: Xunlei Pang
As part of addressing "y2038 problem" for in-kernel uses, this
patch adds the y2038-safe tegra_read_persistent_clock64() using
timespec64.
Because we rely on some subsequent changes to convert arm multiarch
support, tegra_read_persistent_clock() will be removed the
From: Xunlei Pang
Now we have all the read_boot_clock64() for all implementations,
it's time to remove read_boot_clock() completely from the kernel.
Signed-off-by: Xunlei Pang
---
read_persistent_clock() and update_persistent_clock() are way more
complex, so we will deal with them gradually
From: Xunlei Pang
read_boot_clock(), read_persistent_clock() and update_persistent_clock()
all use timespec which may have "y2038 problem", thus we are planning on
converting all of them to use timespec64.
The approach we're using is:
1) First of all, add the "__weak
From: Xunlei Pang
As part of addressing in-kernel y2038 issues, this patch adds
read_boot_clock64() and replaces all the call sites of read_boot_clock()
with this function. This is a __weak implementation, which simply
calls the existing y2038 unsafe read_boot_clock().
This allows architecture
From: Xunlei Pang
As part of addressing "y2038 problem" for in-kernel uses, this
patch adds the y2038-safe omap_read_persistent_clock64() using
timespec64.
Because we rely on some subsequent changes to convert arm multiarch
support, omap_read_persistent_clock() will be removed t
From: Xunlei Pang
As part of addressing in-kernel y2038 issues, this patch adds
read_persistent_clock64() and replaces all the call sites of
read_persistent_clock() with this function. This is a __weak
implementation, which simply calls the existing y2038 unsafe
read_persistent_clock
From: Xunlei Pang
As part of addressing in-kernel y2038 issues, this patch adds
update_persistent_clock64() and replaces all the call sites of
update_persistent_clock() with this function. This is a __weak
implementation, which simply calls the existing y2038 unsafe
update_persistent_clock
From: Xunlei Pang pang.xun...@linaro.org
As part of addressing y2038 problem for in-kernel uses, this
patch converts read_boot_clock() to read_boot_clock64() and
read_persistent_clock() to read_persistent_clock64() using
timespec64 by converting clock_access_fn to use timespec64.
Signed-off
From: Xunlei Pang pang.xun...@linaro.org
As part of addressing y2038 problem for in-kernel uses, this
patch converts read_boot_clock() to read_boot_clock64() and
read_persistent_clock() to read_persistent_clock64() using
timespec64.
Since S390 is a 64bit architecture, also rename some timespec
From: Xunlei Pang pang.xun...@linaro.org
As part of addressing y2038 problem for in-kernel uses, this
patch adds the y2038-safe tegra_read_persistent_clock64() using
timespec64.
Because we rely on some subsequent changes to convert arm multiarch
support, tegra_read_persistent_clock
From: Xunlei Pang pang.xun...@linaro.org
read_boot_clock(), read_persistent_clock() and update_persistent_clock()
all use timespec which may have y2038 problem, thus we are planning on
converting all of them to use timespec64.
The approach we're using is:
1) First of all, add the __weak
From: Xunlei Pang pang.xun...@linaro.org
Now we have all the read_boot_clock64() for all implementations,
it's time to remove read_boot_clock() completely from the kernel.
Signed-off-by: Xunlei Pang pang.xun...@linaro.org
---
read_persistent_clock() and update_persistent_clock() are way more
From: Xunlei Pang pang.xun...@linaro.org
As part of addressing in-kernel y2038 issues, this patch adds
read_persistent_clock64() and replaces all the call sites of
read_persistent_clock() with this function. This is a __weak
implementation, which simply calls the existing y2038 unsafe
From: Xunlei Pang pang.xun...@linaro.org
As part of addressing in-kernel y2038 issues, this patch adds
update_persistent_clock64() and replaces all the call sites of
update_persistent_clock() with this function. This is a __weak
implementation, which simply calls the existing y2038 unsafe
From: Xunlei Pang pang.xun...@linaro.org
As part of addressing in-kernel y2038 issues, this patch adds
read_boot_clock64() and replaces all the call sites of read_boot_clock()
with this function. This is a __weak implementation, which simply
calls the existing y2038 unsafe read_boot_clock
From: Xunlei Pang pang.xun...@linaro.org
As part of addressing y2038 problem for in-kernel uses, this
patch adds the y2038-safe omap_read_persistent_clock64() using
timespec64.
Because we rely on some subsequent changes to convert arm multiarch
support, omap_read_persistent_clock
From: Xunlei Pang
If there're multiple nodes with the same prio as @node, currently
plist_add() will add @node behind all of them. Now we need to add
@node before all of these nodes for SMP RT scheduler.
This patch adds a common __plist_add() for adding @node before or
after existing nodes
From: Xunlei Pang
Currently, SMP RT scheduler has some trouble in dealing with
equal prio cases.
For example, in check_preempt_equal_prio():
When RT1(current task) gets preempted by RT2, if there is a
migratable RT3 with same prio, RT3 will be pushed away instead
of RT1 afterwards, because RT1
From: Xunlei Pang
We may suffer from extra rt overload rq due to the affinity,
so when the affinity of any runnable rt task is changed, we
should check to trigger balancing, otherwise it will cause
some unnecessary delayed real-time response. Unfortunately,
current RT global scheduler doesn't
From: Xunlei Pang
rtc_read_time() has already judged valid tm by rtc_valid_tm(),
so just remove it.
Signed-off-by: Xunlei Pang
---
drivers/rtc/class.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
index 74a943e..c29ba7e 100644
--- a/drivers
From: Xunlei Pang
If a system does not provide a persistent_clock(), the time
will be updated on resume by rtc_resume(). With the addition
of the non-stop clocksources for suspend timing, those systems
set the time on resume in timekeeping_resume(), but may not
provide a valid persistent_clock
From: Xunlei Pang
When there's no persistent clock, normally timekeeping_suspend_time
should always be zero, but this can break in timekeeping_suspend().
At T1, there was a system suspend, so old_delta was assigned T1.
After some time, one time adjustment happened, and xtime got the
value of T1
From: Xunlei Pang
timekeeping_inject_sleeptime64() is only used by RTC suspend/resume,
so embrace it in RTC related macros.
Signed-off-by: Xunlei Pang
---
v5 changes:
Remove CONFIG_RTC_CLASS.
kernel/time/timekeeping.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/time
From: Xunlei Pang pang.xun...@linaro.org
If a system does not provide a persistent_clock(), the time
will be updated on resume by rtc_resume(). With the addition
of the non-stop clocksources for suspend timing, those systems
set the time on resume in timekeeping_resume(), but may not
provide
From: Xunlei Pang pang.xun...@linaro.org
When there's no persistent clock, normally timekeeping_suspend_time
should always be zero, but this can break in timekeeping_suspend().
At T1, there was a system suspend, so old_delta was assigned T1.
After some time, one time adjustment happened
From: Xunlei Pang pang.xun...@linaro.org
timekeeping_inject_sleeptime64() is only used by RTC suspend/resume,
so embrace it in RTC related macros.
Signed-off-by: Xunlei Pang pang.xun...@linaro.org
---
v5 changes:
Remove CONFIG_RTC_CLASS.
kernel/time/timekeeping.c | 2 ++
1 file changed, 2
From: Xunlei Pang pang.xun...@linaro.org
We may suffer from extra rt overload rq due to the affinity,
so when the affinity of any runnable rt task is changed, we
should check to trigger balancing, otherwise it will cause
some unnecessary delayed real-time response. Unfortunately,
current RT
From: Xunlei Pang pang.xun...@linaro.org
rtc_read_time() has already judged valid tm by rtc_valid_tm(),
so just remove it.
Signed-off-by: Xunlei Pang pang.xun...@linaro.org
---
drivers/rtc/class.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
From: Xunlei Pang pang.xun...@linaro.org
Currently, SMP RT scheduler has some trouble in dealing with
equal prio cases.
For example, in check_preempt_equal_prio():
When RT1(current task) gets preempted by RT2, if there is a
migratable RT3 with same prio, RT3 will be pushed away instead
of RT1
From: Xunlei Pang pang.xun...@linaro.org
If there're multiple nodes with the same prio as @node, currently
plist_add() will add @node behind all of them. Now we need to add
@node before all of these nodes for SMP RT scheduler.
This patch adds a common __plist_add() for adding @node before
From: Xunlei Pang
We may suffer from extra rt overload rq due to the affinity,
so when the affinity of any runnable rt task is changed, we
should check to trigger balancing, otherwise it will cause
some unnecessary delayed real-time response. Unfortunately,
current RT global scheduler doesn't
From: Xunlei Pang
If there're multiple nodes with the same prio as @node, currently
plist_add() will add @node behind all of them. Now we need to add
@node before all of these nodes for SMP RT scheduler.
This patch adds a common __plist_add() for adding @node before or
behind existing nodes
From: Xunlei Pang
Currently, SMP RT scheduler has some trouble in dealing with
equal prio cases.
For example, in check_preempt_equal_prio():
When RT1(current task) gets preempted by RT2, if there is a
migratable RT3 with same prio, RT3 will be pushed away instead
of RT1 afterwards, because RT1
From: Xunlei Pang pang.xun...@linaro.org
If there're multiple nodes with the same prio as @node, currently
plist_add() will add @node behind all of them. Now we need to add
@node before all of these nodes for SMP RT scheduler.
This patch adds a common __plist_add() for adding @node before
From: Xunlei Pang pang.xun...@linaro.org
Currently, SMP RT scheduler has some trouble in dealing with
equal prio cases.
For example, in check_preempt_equal_prio():
When RT1(current task) gets preempted by RT2, if there is a
migratable RT3 with same prio, RT3 will be pushed away instead
of RT1
From: Xunlei Pang pang.xun...@linaro.org
We may suffer from extra rt overload rq due to the affinity,
so when the affinity of any runnable rt task is changed, we
should check to trigger balancing, otherwise it will cause
some unnecessary delayed real-time response. Unfortunately,
current RT
From: Xunlei Pang
If a system does not provide a persistent_clock(), the time
will be updated on resume by rtc_resume(). With the addition
of the non-stop clocksources for suspend timing, those systems
set the time on resume in timekeeping_resume(), but may not
provide a valid persistent_clock
From: Xunlei Pang
timekeeping_inject_sleeptime64() is only used by RTC suspend/resume,
so embrace it in RTC related macros.
Signed-off-by: Xunlei Pang
---
kernel/time/timekeeping.c | 4
1 file changed, 4 insertions(+)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
From: Xunlei Pang
When there's no persistent clock, normally timekeeping_suspend_time
should always be zero, but this can break in timekeeping_suspend().
At T1, there was a system suspend, so old_delta was assigned T1.
After some time, one time adjustment happened, and xtime got the
value of T1
From: Xunlei Pang
rtc_read_time() has already judged valid tm by rtc_valid_tm(),
so just remove it.
Signed-off-by: Xunlei Pang
---
drivers/rtc/class.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
index 74a943e..c29ba7e 100644
--- a/drivers
From: Xunlei Pang pang.xun...@linaro.org
rtc_read_time() has already judged valid tm by rtc_valid_tm(),
so just remove it.
Signed-off-by: Xunlei Pang pang.xun...@linaro.org
---
drivers/rtc/class.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
From: Xunlei Pang pang.xun...@linaro.org
When there's no persistent clock, normally timekeeping_suspend_time
should always be zero, but this can break in timekeeping_suspend().
At T1, there was a system suspend, so old_delta was assigned T1.
After some time, one time adjustment happened
From: Xunlei Pang pang.xun...@linaro.org
If a system does not provide a persistent_clock(), the time
will be updated on resume by rtc_resume(). With the addition
of the non-stop clocksources for suspend timing, those systems
set the time on resume in timekeeping_resume(), but may not
provide
From: Xunlei Pang pang.xun...@linaro.org
timekeeping_inject_sleeptime64() is only used by RTC suspend/resume,
so embrace it in RTC related macros.
Signed-off-by: Xunlei Pang pang.xun...@linaro.org
---
kernel/time/timekeeping.c | 4
1 file changed, 4 insertions(+)
diff --git a/kernel/time
Hi Steve,
On 13 February 2015 at 11:55, Xunlei Pang wrote:
> Hi steve,
>
> On 13 February 2015 at 08:04, Steven Rostedt wrote:
>> On Sun, 8 Feb 2015 23:51:26 +0800
>> Xunlei Pang wrote:
>>
>>> check_preempt_curr() doesn't call sched_class::check_preemp
Hi steve,
On 13 February 2015 at 08:04, Steven Rostedt wrote:
> On Sun, 8 Feb 2015 23:51:26 +0800
> Xunlei Pang wrote:
>
>> check_preempt_curr() doesn't call sched_class::check_preempt_curr
>> when the class of current is a higher level.
>
> The above sentence d
On 13 February 2015 at 07:31, Steven Rostedt wrote:
> On Sun, 8 Feb 2015 23:51:25 +0800
> Xunlei Pang wrote:
>
>
>> + if (new_weight > 1 &&
>> + rt_task(rq->curr) &&
>> + !test_tsk_need_resched(rq->curr)) {
>>
Hi steve,
On 13 February 2015 at 08:04, Steven Rostedt rost...@goodmis.org wrote:
On Sun, 8 Feb 2015 23:51:26 +0800
Xunlei Pang pang.xun...@linaro.org wrote:
check_preempt_curr() doesn't call sched_class::check_preempt_curr
when the class of current is a higher level.
The above sentence
Hi Steve,
On 13 February 2015 at 11:55, Xunlei Pang pang.xun...@linaro.org wrote:
Hi steve,
On 13 February 2015 at 08:04, Steven Rostedt rost...@goodmis.org wrote:
On Sun, 8 Feb 2015 23:51:26 +0800
Xunlei Pang pang.xun...@linaro.org wrote:
check_preempt_curr() doesn't call sched_class
On 13 February 2015 at 07:31, Steven Rostedt rost...@goodmis.org wrote:
On Sun, 8 Feb 2015 23:51:25 +0800
Xunlei Pang pang.xun...@linaro.org wrote:
+ if (new_weight 1
+ rt_task(rq-curr)
+ !test_tsk_need_resched(rq-curr)) {
+ /*
+ * We own p
Hi John,
On 11 February 2015 at 08:01, John Stultz wrote:
> On Thu, Jan 29, 2015 at 11:59 PM, Xunlei Pang wrote:
>> From: Xunlei Pang
>>
>> If a system does not provide a persistent_clock(), the time
>> will be updated on resume by rtc_resume(). With the
Hi John,
On 11 February 2015 at 08:01, John Stultz john.stu...@linaro.org wrote:
On Thu, Jan 29, 2015 at 11:59 PM, Xunlei Pang xlp...@126.com wrote:
From: Xunlei Pang pang.xun...@linaro.org
If a system does not provide a persistent_clock(), the time
will be updated on resume by rtc_resume
schedule(), this
definitely causes some/big response latency for rt2.
So, when doing set_cpus_allowed_rt(), if detecting such cases,
check to trigger a push behaviour.
Signed-off-by: Xunlei Pang
---
v2, v3:
Refine according to Steven Rostedt's comments.
kernel/sched/rt.c | 78
check_preempt_equal_prio()
here is that we just don't care whether RT2 is migratable.
- Otherwise, if there's no rt task with the same priority as RT1,
RT1 will still be picked as the running task after the requeuing.
Signed-off-by: Xunlei Pang
---
kernel/sched/rt.c | 16
1 file changed
On 8 February 2015 at 22:55, Xunlei Pang wrote:
> Hi Steve,
>
> On 7 February 2015 at 05:09, Steven Rostedt wrote:
>> On Thu, 5 Feb 2015 23:59:33 +0800
>>
>> if (task_running(rq, p)) {
>> if (cpumask_test_cpu() && cpupri_find())
Hi Steve,
On 7 February 2015 at 05:09, Steven Rostedt wrote:
> On Thu, 5 Feb 2015 23:59:33 +0800
>> +
>> + if (task_running(rq, p) &&
>> + cpumask_test_cpu(task_cpu(p), new_mask) &&
>
> Why the check for task_cpu being in new_mask?
If the current cpu of this task is
On 8 February 2015 at 22:55, Xunlei Pang pang.xun...@linaro.org wrote:
Hi Steve,
On 7 February 2015 at 05:09, Steven Rostedt rost...@goodmis.org wrote:
On Thu, 5 Feb 2015 23:59:33 +0800
if (task_running(rq, p)) {
if (cpumask_test_cpu() cpupri_find
schedule(), this
definitely causes some/big response latency for rt2.
So, when doing set_cpus_allowed_rt(), if detecting such cases,
check to trigger a push behaviour.
Signed-off-by: Xunlei Pang pang.xun...@linaro.org
---
v2, v3:
Refine according to Steven Rostedt's comments.
kernel/sched/rt.c | 78
check_preempt_equal_prio()
here is that we just don't care whether RT2 is migratable.
- Otherwise, if there's no rt task with the same priority as RT1,
RT1 will still be picked as the running task after the requeuing.
Signed-off-by: Xunlei Pang pang.xun...@linaro.org
---
kernel/sched/rt.c | 16
801 - 900 of 1061 matches
Mail list logo
