There are some 64 bits variables in cfs_rq/tg etc. That ask expersive
operations in 32 bit machine. But in fact, long type is enough for them.
So do this change lead more efficient code and without data lose.
Regards
Alex
Since tg->load_avg is smaller than tg->load_weight, we don't need a
atomic64_t variable for load_avg in 32 bit machine.
The same reason for cfs_rq->tg_load_contrib.
The atomic_long_t/unsigned long variable type are more efficient and
convenience for them.
Signed-off-by: Alex Shi <[email protected]>
---
kernel/sched/debug.c | 6 +++---
kernel/sched/fair.c | 12 ++++++------
kernel/sched/sched.h | 4 ++--
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index 160afdc..d803989 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -215,9 +215,9 @@ void print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq)
cfs_rq->runnable_load_avg);
SEQ_printf(m, " .%-30s: %ld\n", "blocked_load_avg",
cfs_rq->blocked_load_avg);
- SEQ_printf(m, " .%-30s: %lld\n", "tg_load_avg",
- (unsigned long long)atomic64_read(&cfs_rq->tg->load_avg));
- SEQ_printf(m, " .%-30s: %lld\n", "tg_load_contrib",
+ SEQ_printf(m, " .%-30s: %ld\n", "tg_load_avg",
+ atomic_long_read(&cfs_rq->tg->load_avg));
+ SEQ_printf(m, " .%-30s: %ld\n", "tg_load_contrib",
cfs_rq->tg_load_contrib);
SEQ_printf(m, " .%-30s: %d\n", "tg_runnable_contrib",
cfs_rq->tg_runnable_contrib);
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 985d47e..30fb7dc 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1075,7 +1075,7 @@ static inline long calc_tg_weight(struct task_group *tg, struct cfs_rq *cfs_rq)
* to gain a more accurate current total weight. See
* update_cfs_rq_load_contribution().
*/
- tg_weight = atomic64_read(&tg->load_avg);
+ tg_weight = atomic_long_read(&tg->load_avg);
tg_weight -= cfs_rq->tg_load_contrib;
tg_weight += cfs_rq->load.weight;
@@ -1356,13 +1356,13 @@ static inline void __update_cfs_rq_tg_load_contrib(struct cfs_rq *cfs_rq,
int force_update)
{
struct task_group *tg = cfs_rq->tg;
- s64 tg_contrib;
+ long tg_contrib;
tg_contrib = cfs_rq->runnable_load_avg;
tg_contrib -= cfs_rq->tg_load_contrib;
- if (force_update || abs64(tg_contrib) > cfs_rq->tg_load_contrib / 8) {
- atomic64_add(tg_contrib, &tg->load_avg);
+ if (force_update || abs(tg_contrib) > cfs_rq->tg_load_contrib / 8) {
+ atomic_long_add(tg_contrib, &tg->load_avg);
cfs_rq->tg_load_contrib += tg_contrib;
}
}
@@ -1397,8 +1397,8 @@ static inline void __update_group_entity_contrib(struct sched_entity *se)
u64 contrib;
contrib = cfs_rq->tg_load_contrib * tg->shares;
- se->avg.load_avg_contrib = div64_u64(contrib,
- atomic64_read(&tg->load_avg) + 1);
+ se->avg.load_avg_contrib = div_u64(contrib,
+ atomic_long_read(&tg->load_avg) + 1);
/*
* For group entities we need to compute a correction term in the case
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 5a80943..1bfa91a 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -150,7 +150,7 @@ struct task_group {
atomic_t load_weight;
#ifdef CONFIG_SMP
- atomic64_t load_avg;
+ atomic_long_t load_avg;
atomic_t runnable_avg;
#endif
#endif
@@ -284,7 +284,7 @@ struct cfs_rq {
#ifdef CONFIG_FAIR_GROUP_SCHED
/* Required to track per-cpu representation of a task_group */
u32 tg_runnable_contrib;
- u64 tg_load_contrib;
+ unsigned long tg_load_contrib;
#endif /* CONFIG_FAIR_GROUP_SCHED */
/*
--
1.7.12
Since no one use it.
Signed-off-by: Alex Shi <[email protected]>
---
kernel/sched/sched.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 874731f..09e2719 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -148,7 +148,6 @@ struct task_group {
struct cfs_rq **cfs_rq;
unsigned long shares;
- atomic_t load_weight;
#ifdef CONFIG_SMP
atomic_long_t load_avg;
atomic_t runnable_avg;
--
1.7.12
Like as runnable_load_avg, blocked_load_avg variable, long type is
enough for removed_load in 64 bit or 32 bit machine.
Then we avoid the expensive atomic64 operations on 32 bit machine.
Signed-off-by: Alex Shi <[email protected]>
---
kernel/sched/fair.c | 10 ++++++----
kernel/sched/sched.h | 3 ++-
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 30fb7dc..9cc4211 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1517,8 +1517,9 @@ static void update_cfs_rq_blocked_load(struct cfs_rq *cfs_rq, int force_update)
if (!decays && !force_update)
return;
- if (atomic64_read(&cfs_rq->removed_load)) {
- u64 removed_load = atomic64_xchg(&cfs_rq->removed_load, 0);
+ if (atomic_long_read(&cfs_rq->removed_load)) {
+ unsigned long removed_load;
+ removed_load = atomic_long_xchg(&cfs_rq->removed_load, 0);
subtract_blocked_load_contrib(cfs_rq, removed_load);
}
@@ -3479,7 +3480,8 @@ migrate_task_rq_fair(struct task_struct *p, int next_cpu)
*/
if (se->avg.decay_count) {
se->avg.decay_count = -__synchronize_entity_decay(se);
- atomic64_add(se->avg.load_avg_contrib, &cfs_rq->removed_load);
+ atomic_long_add(se->avg.load_avg_contrib,
+ &cfs_rq->removed_load);
}
}
#endif /* CONFIG_SMP */
@@ -5944,7 +5946,7 @@ void init_cfs_rq(struct cfs_rq *cfs_rq)
#endif
#if defined(CONFIG_FAIR_GROUP_SCHED) && defined(CONFIG_SMP)
atomic64_set(&cfs_rq->decay_counter, 1);
- atomic64_set(&cfs_rq->removed_load, 0);
+ atomic_long_set(&cfs_rq->removed_load, 0);
#endif
}
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 1bfa91a..874731f 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -278,8 +278,9 @@ struct cfs_rq {
* the FAIR_GROUP_SCHED case).
*/
unsigned long runnable_load_avg, blocked_load_avg;
- atomic64_t decay_counter, removed_load;
+ atomic64_t decay_counter;
u64 last_decay;
+ atomic_long_t removed_load;
#ifdef CONFIG_FAIR_GROUP_SCHED
/* Required to track per-cpu representation of a task_group */
--
1.7.12
Since the 'u64 runnable_load_avg, blocked_load_avg' in cfs_rq struct are
smaller than 'unsigned long' cfs_rq->load.weight. We don't need u64
vaiables to describe them. unsigned long is more efficient and convenience.
Signed-off-by: Alex Shi <[email protected]>
---
kernel/sched/debug.c | 4 ++--
kernel/sched/sched.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index 75024a6..160afdc 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -211,9 +211,9 @@ void print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq)
SEQ_printf(m, " .%-30s: %ld\n", "load", cfs_rq->load.weight);
#ifdef CONFIG_FAIR_GROUP_SCHED
#ifdef CONFIG_SMP
- SEQ_printf(m, " .%-30s: %lld\n", "runnable_load_avg",
+ SEQ_printf(m, " .%-30s: %ld\n", "runnable_load_avg",
cfs_rq->runnable_load_avg);
- SEQ_printf(m, " .%-30s: %lld\n", "blocked_load_avg",
+ SEQ_printf(m, " .%-30s: %ld\n", "blocked_load_avg",
cfs_rq->blocked_load_avg);
SEQ_printf(m, " .%-30s: %lld\n", "tg_load_avg",
(unsigned long long)atomic64_read(&cfs_rq->tg->load_avg));
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 8bc66c6..5a80943 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -277,7 +277,7 @@ struct cfs_rq {
* This allows for the description of both thread and group usage (in
* the FAIR_GROUP_SCHED case).
*/
- u64 runnable_load_avg, blocked_load_avg;
+ unsigned long runnable_load_avg, blocked_load_avg;
atomic64_t decay_counter, removed_load;
u64 last_decay;
--
1.7.12
On 7 June 2013 09:29, Alex Shi <[email protected]> wrote:
> Since the 'u64 runnable_load_avg, blocked_load_avg' in cfs_rq struct are
> smaller than 'unsigned long' cfs_rq->load.weight. We don't need u64
> vaiables to describe them. unsigned long is more efficient and convenience.
>
Hi Alex,
I just want to point out that we can't have more than 48388 tasks with
highest priority on a runqueue with an unsigned long on a 32 bits
system. I don't know if we can reach such kind of limit on a 32bits
machine ? For sure, not on an embedded system.
Regards,
Vincent
> Signed-off-by: Alex Shi <[email protected]>
> ---
> kernel/sched/debug.c | 4 ++--
> kernel/sched/sched.h | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
> index 75024a6..160afdc 100644
> --- a/kernel/sched/debug.c
> +++ b/kernel/sched/debug.c
> @@ -211,9 +211,9 @@ void print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq)
> SEQ_printf(m, " .%-30s: %ld\n", "load", cfs_rq->load.weight);
> #ifdef CONFIG_FAIR_GROUP_SCHED
> #ifdef CONFIG_SMP
> - SEQ_printf(m, " .%-30s: %lld\n", "runnable_load_avg",
> + SEQ_printf(m, " .%-30s: %ld\n", "runnable_load_avg",
> cfs_rq->runnable_load_avg);
> - SEQ_printf(m, " .%-30s: %lld\n", "blocked_load_avg",
> + SEQ_printf(m, " .%-30s: %ld\n", "blocked_load_avg",
> cfs_rq->blocked_load_avg);
> SEQ_printf(m, " .%-30s: %lld\n", "tg_load_avg",
> (unsigned long long)atomic64_read(&cfs_rq->tg->load_avg));
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index 8bc66c6..5a80943 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -277,7 +277,7 @@ struct cfs_rq {
> * This allows for the description of both thread and group usage (in
> * the FAIR_GROUP_SCHED case).
> */
> - u64 runnable_load_avg, blocked_load_avg;
> + unsigned long runnable_load_avg, blocked_load_avg;
> atomic64_t decay_counter, removed_load;
> u64 last_decay;
>
> --
> 1.7.12
>
On 06/07/2013 05:07 PM, Vincent Guittot wrote:
> On 7 June 2013 09:29, Alex Shi <[email protected]> wrote:
>> > Since the 'u64 runnable_load_avg, blocked_load_avg' in cfs_rq struct are
>> > smaller than 'unsigned long' cfs_rq->load.weight. We don't need u64
>> > vaiables to describe them. unsigned long is more efficient and convenience.
>> >
> Hi Alex,
>
> I just want to point out that we can't have more than 48388 tasks with
> highest priority on a runqueue with an unsigned long on a 32 bits
> system. I don't know if we can reach such kind of limit on a 32bits
> machine ? For sure, not on an embedded system.
Thanks question!
It should be a talked problem. I just remember the conclusion is when
you get the up bound task number, you already run out the memory space
on 32 bit.
Just for kernel resource for a process, it need 2 pages stack.
mm_struct, task_struct, task_stats, vm_area_struct, page table etc.
these are already beyond 4 pages. so 4 * 4k * 48388 = 774MB. plus user
level resources.
So, usually the limited task number in Linux is often far lower this
number: $ulimit -u.
Anyway, at least, the runnable_load_avg is smaller then load.weight. if
load.weight can use long type, runablle_load_avg is no reason can't.
--
Thanks
Alex
On 06/07/2013 03:29 PM, Alex Shi wrote:
> There are some 64 bits variables in cfs_rq/tg etc. That ask expersive
> operations in 32 bit machine. But in fact, long type is enough for them.
>
> So do this change lead more efficient code and without data lose.
BTW, this patch bases on my v8 patchset: use runnable load in balance.
the git tree is here:
[email protected]:alexshi/power-scheduling.git runnablelb
Any more comments?
>
> Regards
> Alex
>
--
Thanks
Alex
On 06/10/2013 10:20 AM, Alex Shi wrote:
> On 06/07/2013 03:29 PM, Alex Shi wrote:
>> > There are some 64 bits variables in cfs_rq/tg etc. That ask expersive
>> > operations in 32 bit machine. But in fact, long type is enough for them.
>> >
>> > So do this change lead more efficient code and without data lose.
> BTW, this patch bases on my v8 patchset: use runnable load in balance.
> the git tree is here:
> [email protected]:alexshi/power-scheduling.git runnablelb
>
>
> Any more comments?
>
Paul, Could you like to give a bit comments?
--
Thanks
Alex
On 06/07/2013 03:29 PM, Alex Shi wrote:
> There are some 64 bits variables in cfs_rq/tg etc. That ask expersive
> operations in 32 bit machine. But in fact, long type is enough for them.
>
> So do this change lead more efficient code and without data lose.
>
some variable like cfs_rq->runnable_load_avg, there is no much changes
in patch 1/4, since in most of place it was treated as a 'unsigned
long', not u64.
Anyway, Paul, I know you are watching the mailing list. :)
Could you like to give some comments on this patchset?
> Regards
> Alex
>
--
Thanks
Alex
On 06/14/2013 10:20 PM, Alex Shi wrote:
> On 06/07/2013 03:29 PM, Alex Shi wrote:
>> There are some 64 bits variables in cfs_rq/tg etc. That ask expensive
>> operations in 32 bit machine. But in fact, long type is enough for them.
>>
>> So do this change lead more efficient code and without data lose.
>>
>
> some variable like cfs_rq->runnable_load_avg, there is no much changes
> in patch 1/4, since in most of place it was treated as a 'unsigned
> long', not u64.
>
The patchset change some u64 load avg variables to 'unsigned long' type,
because the related load variable is 'unsigned long' too.
Peter,
It looks quite straight. So if Paul is too busy to look into this,
Believe you can do decide independent. :)
>> Regards
>> Alex
>>
>
>
--
Thanks
Alex
On Fri, Jun 7, 2013 at 7:18 PM, Alex Shi <[email protected]> wrote:
> On 06/07/2013 05:07 PM, Vincent Guittot wrote:
>> On 7 June 2013 09:29, Alex Shi <[email protected]> wrote:
>>> > Since the 'u64 runnable_load_avg, blocked_load_avg' in cfs_rq struct are
>>> > smaller than 'unsigned long' cfs_rq->load.weight. We don't need u64
>>> > vaiables to describe them. unsigned long is more efficient and convenience.
>>> >
>> Hi Alex,
>>
>> I just want to point out that we can't have more than 48388 tasks with
>> highest priority on a runqueue with an unsigned long on a 32 bits
>> system. I don't know if we can reach such kind of limit on a 32bits
>> machine ? For sure, not on an embedded system.
This should be ok.
Note that:
runnable_load_avg = \Sum se->load_avg_contrib <= \Sum
se->load.weight = cfs_rq->load.weight
And load_weight uses unsigned longs also.
blocked_load_avg must be also safe since anything appearing in blocked
load could have appeared in runnable load and we've said that was ok
above.
Reviewed-By: Paul Turner <[email protected]>
>
> Thanks question!
> It should be a talked problem. I just remember the conclusion is when
> you get the up bound task number, you already run out the memory space
> on 32 bit.
>
> Just for kernel resource for a process, it need 2 pages stack.
> mm_struct, task_struct, task_stats, vm_area_struct, page table etc.
> these are already beyond 4 pages. so 4 * 4k * 48388 = 774MB. plus user
> level resources.
>
> So, usually the limited task number in Linux is often far lower this
> number: $ulimit -u.
>
> Anyway, at least, the runnable_load_avg is smaller then load.weight. if
> load.weight can use long type, runablle_load_avg is no reason can't.
>
> --
> Thanks
> Alex
On 8 June 2013 04:18, Alex Shi <[email protected]> wrote:
> On 06/07/2013 05:07 PM, Vincent Guittot wrote:
>> On 7 June 2013 09:29, Alex Shi <[email protected]> wrote:
>>> > Since the 'u64 runnable_load_avg, blocked_load_avg' in cfs_rq struct are
>>> > smaller than 'unsigned long' cfs_rq->load.weight. We don't need u64
>>> > vaiables to describe them. unsigned long is more efficient and convenience.
>>> >
>> Hi Alex,
>>
>> I just want to point out that we can't have more than 48388 tasks with
>> highest priority on a runqueue with an unsigned long on a 32 bits
>> system. I don't know if we can reach such kind of limit on a 32bits
>> machine ? For sure, not on an embedded system.
>
> Thanks question!
> It should be a talked problem. I just remember the conclusion is when
> you get the up bound task number, you already run out the memory space
> on 32 bit.
>
> Just for kernel resource for a process, it need 2 pages stack.
> mm_struct, task_struct, task_stats, vm_area_struct, page table etc.
> these are already beyond 4 pages. so 4 * 4k * 48388 = 774MB. plus user
> level resources.
>
> So, usually the limited task number in Linux is often far lower this
> number: $ulimit -u.
>
> Anyway, at least, the runnable_load_avg is smaller then load.weight. if
> load.weight can use long type, runablle_load_avg is no reason can't.
Alex,
You can add my tested-by for this patchset.
Regards,
Vincent
>
> --
> Thanks
> Alex
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On 06/17/2013 05:54 PM, Vincent Guittot wrote:
>> > So, usually the limited task number in Linux is often far lower this
>> > number: $ulimit -u.
>> >
>> > Anyway, at least, the runnable_load_avg is smaller then load.weight. if
>> > load.weight can use long type, runablle_load_avg is no reason can't.
> Alex,
>
> You can add my tested-by for this patchset.
thanks for test!
--
Thanks
Alex
On 06/17/2013 05:49 PM, Paul Turner wrote:
>>> >> Hi Alex,
>>> >>
>>> >> I just want to point out that we can't have more than 48388 tasks with
>>> >> highest priority on a runqueue with an unsigned long on a 32 bits
>>> >> system. I don't know if we can reach such kind of limit on a 32bits
>>> >> machine ? For sure, not on an embedded system.
> This should be ok.
>
> Note that:
> runnable_load_avg = \Sum se->load_avg_contrib <= \Sum
> se->load.weight = cfs_rq->load.weight
>
> And load_weight uses unsigned longs also.
>
> blocked_load_avg must be also safe since anything appearing in blocked
> load could have appeared in runnable load and we've said that was ok
> above.
>
> Reviewed-By: Paul Turner <[email protected]>
>
thanks for review!
--
Thanks
Alex
On Fri, Jun 7, 2013 at 12:29 AM, Alex Shi <[email protected]> wrote:
> Like as runnable_load_avg, blocked_load_avg variable, long type is
> enough for removed_load in 64 bit or 32 bit machine.
>
> Then we avoid the expensive atomic64 operations on 32 bit machine.
>
> Signed-off-by: Alex Shi <[email protected]>
So while this isn't under quite the same constraints as blocked_load
since this is per-migration and only cleared on the tick; it would
take an awful lot (~47k) of wake-upmigrations of a large (nice-20)
task to overflow.
One concern is that this would be potentially user-triggerable using
sched_setaffinity() when combined with a sufficiently low HZ.
Although all this would actually do would strand blocked load on the
cpu, which mostly punishes the cgroup doing this (likely an ok
behavior). If it ever became an issue we could force a
update_cfs_rq_blocked_load() when a removal would result in an
overflow, but I think this is fine for now.
Reviewed-by: Paul Turner <[email protected]>
> ---
> kernel/sched/fair.c | 10 ++++++----
> kernel/sched/sched.h | 3 ++-
> 2 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 30fb7dc..9cc4211 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -1517,8 +1517,9 @@ static void update_cfs_rq_blocked_load(struct cfs_rq *cfs_rq, int force_update)
> if (!decays && !force_update)
> return;
>
> - if (atomic64_read(&cfs_rq->removed_load)) {
> - u64 removed_load = atomic64_xchg(&cfs_rq->removed_load, 0);
> + if (atomic_long_read(&cfs_rq->removed_load)) {
> + unsigned long removed_load;
> + removed_load = atomic_long_xchg(&cfs_rq->removed_load, 0);
> subtract_blocked_load_contrib(cfs_rq, removed_load);
> }
>
> @@ -3479,7 +3480,8 @@ migrate_task_rq_fair(struct task_struct *p, int next_cpu)
> */
> if (se->avg.decay_count) {
> se->avg.decay_count = -__synchronize_entity_decay(se);
> - atomic64_add(se->avg.load_avg_contrib, &cfs_rq->removed_load);
> + atomic_long_add(se->avg.load_avg_contrib,
> + &cfs_rq->removed_load);
> }
> }
> #endif /* CONFIG_SMP */
> @@ -5944,7 +5946,7 @@ void init_cfs_rq(struct cfs_rq *cfs_rq)
> #endif
> #if defined(CONFIG_FAIR_GROUP_SCHED) && defined(CONFIG_SMP)
> atomic64_set(&cfs_rq->decay_counter, 1);
> - atomic64_set(&cfs_rq->removed_load, 0);
> + atomic_long_set(&cfs_rq->removed_load, 0);
> #endif
> }
>
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index 1bfa91a..874731f 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -278,8 +278,9 @@ struct cfs_rq {
> * the FAIR_GROUP_SCHED case).
> */
> unsigned long runnable_load_avg, blocked_load_avg;
> - atomic64_t decay_counter, removed_load;
> + atomic64_t decay_counter;
> u64 last_decay;
> + atomic_long_t removed_load;
>
> #ifdef CONFIG_FAIR_GROUP_SCHED
> /* Required to track per-cpu representation of a task_group */
> --
> 1.7.12
>
On Fri, Jun 7, 2013 at 12:29 AM, Alex Shi <[email protected]> wrote:
> Since no one use it.
>
> Signed-off-by: Alex Shi <[email protected]>
Reviewed-by: Paul Turner <[email protected]>
On Fri, Jun 7, 2013 at 12:29 AM, Alex Shi <[email protected]> wrote:
> Since tg->load_avg is smaller than tg->load_weight, we don't need a
> atomic64_t variable for load_avg in 32 bit machine.
> The same reason for cfs_rq->tg_load_contrib.
This description is incorrect, another patch removes tg->load_weight
for being unused.
Rest seems fine.
On 06/17/2013 08:25 PM, Paul Turner wrote:
> On Fri, Jun 7, 2013 at 12:29 AM, Alex Shi <[email protected]> wrote:
>> > Since tg->load_avg is smaller than tg->load_weight, we don't need a
>> > atomic64_t variable for load_avg in 32 bit machine.
>> > The same reason for cfs_rq->tg_load_contrib.
> This description is incorrect, another patch removes tg->load_weight
> for being unused.
You can say this, but tg->load_weight was designed for the same meaning
as load_avg before. :)
>
> Rest seems fine.
thanks for review.
--
Thanks
Alex
On 06/07/2013 03:29 PM, Alex Shi wrote:
> Since the 'u64 runnable_load_avg, blocked_load_avg' in cfs_rq struct are
> smaller than 'unsigned long' cfs_rq->load.weight. We don't need u64
> vaiables to describe them. unsigned long is more efficient and convenience.
>
update with a a bit clean up in tg_load_down()
---
>From e78ccc55dff1a5ef406a100f6453d0b8c86ca310 Mon Sep 17 00:00:00 2001
From: Alex Shi <[email protected]>
Date: Thu, 6 Jun 2013 20:12:36 +0800
Subject: [PATCH 1/5] sched: change cfs_rq load avg to unsigned long
Since the 'u64 runnable_load_avg, blocked_load_avg' in cfs_rq struct are
smaller than 'unsigned long' cfs_rq->load.weight. We don't need u64
variables to describe them. unsigned long is more efficient and convenience.
Signed-off-by: Alex Shi <[email protected]>
Reviewed-by: Paul Turner <[email protected]>
Tested-by: Vincent Guittot <[email protected]>
---
kernel/sched/debug.c | 4 ++--
kernel/sched/fair.c | 7 ++-----
kernel/sched/sched.h | 2 +-
3 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index 75024a6..160afdc 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -211,9 +211,9 @@ void print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq)
SEQ_printf(m, " .%-30s: %ld\n", "load", cfs_rq->load.weight);
#ifdef CONFIG_FAIR_GROUP_SCHED
#ifdef CONFIG_SMP
- SEQ_printf(m, " .%-30s: %lld\n", "runnable_load_avg",
+ SEQ_printf(m, " .%-30s: %ld\n", "runnable_load_avg",
cfs_rq->runnable_load_avg);
- SEQ_printf(m, " .%-30s: %lld\n", "blocked_load_avg",
+ SEQ_printf(m, " .%-30s: %ld\n", "blocked_load_avg",
cfs_rq->blocked_load_avg);
SEQ_printf(m, " .%-30s: %lld\n", "tg_load_avg",
(unsigned long long)atomic64_read(&cfs_rq->tg->load_avg));
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 395f57c..39a5bae 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4186,12 +4186,9 @@ static int tg_load_down(struct task_group *tg, void *data)
if (!tg->parent) {
load = cpu_rq(cpu)->avg.load_avg_contrib;
} else {
- unsigned long tmp_rla;
- tmp_rla = tg->parent->cfs_rq[cpu]->runnable_load_avg + 1;
-
load = tg->parent->cfs_rq[cpu]->h_load;
- load *= tg->se[cpu]->avg.load_avg_contrib;
- load /= tmp_rla;
+ load = div64_ul(load * tg->se[cpu]->avg.load_avg_contrib,
+ tg->parent->cfs_rq[cpu]->runnable_load_avg + 1);
}
tg->cfs_rq[cpu]->h_load = load;
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 0684c26..762fa63 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -277,7 +277,7 @@ struct cfs_rq {
* This allows for the description of both thread and group usage (in
* the FAIR_GROUP_SCHED case).
*/
- u64 runnable_load_avg, blocked_load_avg;
+ unsigned long runnable_load_avg, blocked_load_avg;
atomic64_t decay_counter, removed_load;
u64 last_decay;
--
1.7.12