Re: [PATCH v10 6/7] sched: Provide runnable_load_avg back to cfs_rq
Hi Yuyang, On Mon, Jul 27, 2015 at 04:34:09AM +0800, Yuyang Du wrote: > On Mon, Jul 27, 2015 at 12:04:20PM +0800, Boqun Feng wrote: > > > ~~~ > > > > > 1) blocked load is more "difficult" to track, hint, migrate. > > > ~~~ > > > > I may not get your point here? Are you saying my patch fails to handle > > the migration or are you just telling me that blocked load tracking need > > to take migration into consideration? > > Both, is it so difficult to get? > Hmm.. I will appreciate more if you comment on my patch to point out where is wrong ;-) > > If it's the latter one, I want to say that, with blocked load or not, we > > have to handle load_avg in migrations, so *adding* some code to handle > > blocked load is not a big deal. > > > > Please consider this piece of code in update_cfs_rq_load_avg(), which > > decays and updates blocked_load_avg. > > At this point of time, you tell me why exactly you want to track the blocked? I want to track the blocked load because you want to track runnable load in your patch, and as you've already tracked load_avg, which is the sum of blocked load and runnable load, so I wonder whether tracking blocked load is *another* way to track runnable load. Because if tracking blocked load costs less than tracking runnable load, it's of course better to track blocked load and calculate runnable load on demand rather than track runnable load directly. Yes, I do need to decay and update blocked_load_avg in update_cfs_rq_load_avg() if there is a *non-zero* value of remove_load_avg, but: 1. if no entity is migrated and no entity is dequeued(blocked), I need to do nothing but tracking runnable load directly still needs to update runnable load, for example, in entity_tick(). 2. if no entity is migrated and a entity is dequeued(blocked), what I need to do is similar as tracking runnable load directly does. and of course: 3. if a entity is migrated, I do need to do more than tracking runnable load directly. So, For #1 situations, tracking blocked load wins For #2 situations, tie For #3 situations, tracking runnable load wins And which are more rare in the system, #1 or #3? I write that patch to see how much we need to track blocked load *instead* of runnable load, and I don't see that costs a lot. So I basically want to know, is my patch of tracking blocked wrong? If not, does that cost more than or nearly equal to tracking runnable load directly? If not, why not track blocked load instead of tracking runnable load? However, I admit all the questions should be answered by real benchmarks. I just want to see whether you have thought the same questions as I and could give me a quick answer. But I think an simple and directly answer is that "because we need runnable load so we track it", code simplicity wins! if your current answer is that, I'm OK with it, and will do some benchmark myself to see whether it's worth to track blocked load rather than runnable load directly. Again, I still hope a quick and convinced answer from you. Thank you ;-) Regards, Boqun signature.asc Description: PGP signature
Re: [PATCH v10 6/7] sched: Provide runnable_load_avg back to cfs_rq
On Mon, Jul 27, 2015 at 12:04:20PM +0800, Boqun Feng wrote: > > ~~~ > > > > 1) blocked load is more "difficult" to track, hint, migrate. > > ~~~ > > I may not get your point here? Are you saying my patch fails to handle > the migration or are you just telling me that blocked load tracking need > to take migration into consideration? Both, is it so difficult to get? > If it's the latter one, I want to say that, with blocked load or not, we > have to handle load_avg in migrations, so *adding* some code to handle > blocked load is not a big deal. > > Please consider this piece of code in update_cfs_rq_load_avg(), which > decays and updates blocked_load_avg. At this point of time, you tell me why exactly you want to track the blocked? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 6/7] sched: Provide runnable_load_avg back to cfs_rq
Hi Yuyang, On Mon, Jul 27, 2015 at 03:56:34AM +0800, Yuyang Du wrote: > On Mon, Jul 27, 2015 at 11:21:15AM +0800, Boqun Feng wrote: > > Hi Yuyang, > > > > On Mon, Jul 27, 2015 at 02:43:25AM +0800, Yuyang Du wrote: > > > Hi Boqun, > > > > > > On Tue, Jul 21, 2015 at 06:29:56PM +0800, Boqun Feng wrote: > > > > The point is that you have already tracked the sum of runnable_load_avg > > > > and blocked_load_avg in cfs_rq->avg.load_avg. If you're going to track > > > > part of the sum, you'd better track the one that's updated less > > > > frequently, right? > > > > > > > > Anyway, this idea just comes into my mind. I wonder which is udpated > > > > less frequently myself too. ;-) So I ask to see whether there is > > > > something we can improve. > > > > > > Actually, this is not the point. > > > > > ~~~ > > > 1) blocked load is more "difficult" to track, hint, migrate. > ~~~ I may not get your point here? Are you saying my patch fails to handle the migration or are you just telling me that blocked load tracking need to take migration into consideration? If it's the latter one, I want to say that, with blocked load or not, we have to handle load_avg in migrations, so *adding* some code to handle blocked load is not a big deal. Please consider this piece of code in update_cfs_rq_load_avg(), which decays and updates blocked_load_avg. @@ -2656,6 +2670,12 @@ static inline int update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq) long r = atomic_long_xchg(&cfs_rq->removed_load_avg, 0); sa->load_avg = max_t(long, sa->load_avg - r, 0); sa->load_sum = max_t(s64, sa->load_sum - r * LOAD_AVG_MAX, 0); + + decay_cfs_rq_blocked_load(sa->last_update_time, cfs_rq); + cfs_rq->blocked_load_avg = max_t(long, + cfs_rq->blocked_load_avg - r, 0); + cfs_rq->blocked_load_sum = max_t(s64, + cfs_rq->blocked_load_avg - r * LOAD_AVG_MAX, 0); } Regards, Boqun signature.asc Description: PGP signature
Re: [PATCH v10 6/7] sched: Provide runnable_load_avg back to cfs_rq
On Mon, Jul 27, 2015 at 11:21:15AM +0800, Boqun Feng wrote: > Hi Yuyang, > > On Mon, Jul 27, 2015 at 02:43:25AM +0800, Yuyang Du wrote: > > Hi Boqun, > > > > On Tue, Jul 21, 2015 at 06:29:56PM +0800, Boqun Feng wrote: > > > The point is that you have already tracked the sum of runnable_load_avg > > > and blocked_load_avg in cfs_rq->avg.load_avg. If you're going to track > > > part of the sum, you'd better track the one that's updated less > > > frequently, right? > > > > > > Anyway, this idea just comes into my mind. I wonder which is udpated > > > less frequently myself too. ;-) So I ask to see whether there is > > > something we can improve. > > > > Actually, this is not the point. > > ~~~ > > 1) blocked load is more "difficult" to track, hint, migrate. ~~~ > > 2) r(t1) - b(t2) is not anything, hint, t1 != t2 > > Please consider this patch below, which is not tested yet, just for > discussion. This patch is based on 1-5 in your patchset and going to > replace patch 6. Hope this could make my point clear. > > Thanks anyway for being patient with me ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 6/7] sched: Provide runnable_load_avg back to cfs_rq
On Wed, Jul 22, 2015 at 10:19:54AM +0800, Boqun Feng wrote:
>
> > +/* Remove the runnable load generated by se from cfs_rq's runnable load
> > average */
> > +static inline void
> > +dequeue_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se)
> > +{
> > + update_load_avg(se, 1);
> > +
>
> I think we need an update_cfs_rq_load_avg() here? Because the
> runnable_load_avg may not be up to date when dequeue_entity_load_avg()
> is called, right?
Not in update_load_avg()?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 6/7] sched: Provide runnable_load_avg back to cfs_rq
On Mon, Jul 27, 2015 at 11:21:15AM +0800, Boqun Feng wrote:
> Hi Yuyang,
>
> On Mon, Jul 27, 2015 at 02:43:25AM +0800, Yuyang Du wrote:
> > Hi Boqun,
> >
> > On Tue, Jul 21, 2015 at 06:29:56PM +0800, Boqun Feng wrote:
> > > The point is that you have already tracked the sum of runnable_load_avg
> > > and blocked_load_avg in cfs_rq->avg.load_avg. If you're going to track
> > > part of the sum, you'd better track the one that's updated less
> > > frequently, right?
> > >
> > > Anyway, this idea just comes into my mind. I wonder which is udpated
> > > less frequently myself too. ;-) So I ask to see whether there is
> > > something we can improve.
> >
> > Actually, this is not the point.
> >
> > 1) blocked load is more "difficult" to track, hint, migrate.
> >
> > 2) r(t1) - b(t2) is not anything, hint, t1 != t2
>
> Please consider this patch below, which is not tested yet, just for
> discussion. This patch is based on 1-5 in your patchset and going to
> replace patch 6. Hope this could make my point clear.
>
> Thanks anyway for being patient with me ;-)
>
> Regards,
> Boqun
>
>
>
> Subject: [PATCH] sched: lazy blocked load tracking
>
> With this patch, cfs_rq_runnable_load_avg can be implemented as follow:
>
> static inline unsigned long cfs_rq_runnable_load_avg(struct cfs_rq *cfs_rq)
> {
> u64 now = cfs_rq_clock_task(cfs_rq);
> decay_cfs_rq_blocked_load(now, cfs_rq);
>
> return max_t(long, cfs_rq->avg.load_avg - cfs_rq->blocked_load_avg, 0);
> }
>
> ---
> kernel/sched/fair.c | 41 +
> kernel/sched/sched.h | 4
> 2 files changed, 45 insertions(+)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index e977074..76beb81 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -2625,6 +2625,20 @@ static __always_inline int __update_load_avg(u64 now,
> int cpu,
> return decayed;
> }
>
> +static inline u64 decay_cfs_rq_blocked_load(u64 now, struct cfs_rq *cfs_rq)
> +{
> + u64 decays;
> +
> + now = now >> 20;
> + decays = now - cfs_rq->last_blocked_load_decays;
> +
> + cfs_rq->blocked_load_sum = decay_load(cfs_rq->blocked_load_sum, decays);
> + cfs_rq->blocked_load_avg = div_u64(cfs->blocked_load_sum, LOAD_AVG_MAX);
> + cfs_rq->last_blocked_load_update_time = now;
Sorry for the typo, should be last_blocked_load_decays here ;-)
Regards,
Boqun
signature.asc
Description: PGP signature
Re: [PATCH v10 6/7] sched: Provide runnable_load_avg back to cfs_rq
Hi Yuyang,
On Mon, Jul 27, 2015 at 02:43:25AM +0800, Yuyang Du wrote:
> Hi Boqun,
>
> On Tue, Jul 21, 2015 at 06:29:56PM +0800, Boqun Feng wrote:
> > The point is that you have already tracked the sum of runnable_load_avg
> > and blocked_load_avg in cfs_rq->avg.load_avg. If you're going to track
> > part of the sum, you'd better track the one that's updated less
> > frequently, right?
> >
> > Anyway, this idea just comes into my mind. I wonder which is udpated
> > less frequently myself too. ;-) So I ask to see whether there is
> > something we can improve.
>
> Actually, this is not the point.
>
> 1) blocked load is more "difficult" to track, hint, migrate.
>
> 2) r(t1) - b(t2) is not anything, hint, t1 != t2
Please consider this patch below, which is not tested yet, just for
discussion. This patch is based on 1-5 in your patchset and going to
replace patch 6. Hope this could make my point clear.
Thanks anyway for being patient with me ;-)
Regards,
Boqun
Subject: [PATCH] sched: lazy blocked load tracking
With this patch, cfs_rq_runnable_load_avg can be implemented as follow:
static inline unsigned long cfs_rq_runnable_load_avg(struct cfs_rq *cfs_rq)
{
u64 now = cfs_rq_clock_task(cfs_rq);
decay_cfs_rq_blocked_load(now, cfs_rq);
return max_t(long, cfs_rq->avg.load_avg - cfs_rq->blocked_load_avg, 0);
}
---
kernel/sched/fair.c | 41 +
kernel/sched/sched.h | 4
2 files changed, 45 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index e977074..76beb81 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2625,6 +2625,20 @@ static __always_inline int __update_load_avg(u64 now,
int cpu,
return decayed;
}
+static inline u64 decay_cfs_rq_blocked_load(u64 now, struct cfs_rq *cfs_rq)
+{
+ u64 decays;
+
+ now = now >> 20;
+ decays = now - cfs_rq->last_blocked_load_decays;
+
+ cfs_rq->blocked_load_sum = decay_load(cfs_rq->blocked_load_sum, decays);
+ cfs_rq->blocked_load_avg = div_u64(cfs->blocked_load_sum, LOAD_AVG_MAX);
+ cfs_rq->last_blocked_load_update_time = now;
+
+ return decays;
+}
+
#ifdef CONFIG_FAIR_GROUP_SCHED
/*
* Updating tg's load_avg is necessary before update_cfs_share (which is done)
@@ -2656,6 +2670,12 @@ static inline int update_cfs_rq_load_avg(u64 now, struct
cfs_rq *cfs_rq)
long r = atomic_long_xchg(&cfs_rq->removed_load_avg, 0);
sa->load_avg = max_t(long, sa->load_avg - r, 0);
sa->load_sum = max_t(s64, sa->load_sum - r * LOAD_AVG_MAX, 0);
+
+ decay_cfs_rq_blocked_load(sa->last_update_time, cfs_rq);
+ cfs_rq->blocked_load_avg = max_t(long,
+ cfs_rq->blocked_load_avg - r, 0);
+ cfs_rq->blocked_load_sum = max_t(s64,
+ cfs_rq->blocked_load_avg - r * LOAD_AVG_MAX, 0);
}
if (atomic_long_read(&cfs_rq->removed_util_avg)) {
@@ -2719,11 +2739,32 @@ enqueue_entity_load_avg(struct cfs_rq *cfs_rq, struct
sched_entity *se)
cfs_rq->avg.util_avg += sa->util_avg;
cfs_rq->avg.util_sum += sa->util_sum;
}
+ else {
+ decay_cfs_rq_blocked_load(now, cfs_rq);
+
+ cfs_rq->blocked_load_avg = max_t(long,
+ cfs_rq->blocked_load_avg - sa->load_avg, 0);
+ cfs_rq->blocked_load_sum = max_t(long,
+ cfs_rq->blocked_load_sum - sa->load_sum, 0);
+ }
if (decayed || migrated)
update_tg_load_avg(cfs_rq, 0);
}
+static inline void
+dequeue_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se)
+{
+ u64 now = cfs_rq_clock_task(cfs_rq);
+
+ update_load_avg(se, 1);
+ update_cfs_rq_load_avg(now, cfs_rq);
+ decay_cfs_rq_blocked_load(now, cfs_rq);
+
+ cfs_rq->blocked_load_sum += se->avg.load_sum;
+ cfs_rq->blocked_load_avg += se->avg.load_avg;
+}
+
/*
* Task first catches up with cfs_rq, and then subtract
* itself from the cfs_rq (task must be off the queue now).
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 4d139e0..f570306 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -368,6 +368,10 @@ struct cfs_rq {
* CFS load tracking
*/
struct sched_avg avg;
+
+ u64 last_blocked_load_decays;
+ u64 blocked_load_sum;
+ unsigned long blocked_load_avg;
#ifdef CONFIG_FAIR_GROUP_SCHED
unsigned long tg_load_avg_contrib;
#endif
--
2.4.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 6/7] sched: Provide runnable_load_avg back to cfs_rq
Hi Boqun, On Tue, Jul 21, 2015 at 06:29:56PM +0800, Boqun Feng wrote: > The point is that you have already tracked the sum of runnable_load_avg > and blocked_load_avg in cfs_rq->avg.load_avg. If you're going to track > part of the sum, you'd better track the one that's updated less > frequently, right? > > Anyway, this idea just comes into my mind. I wonder which is udpated > less frequently myself too. ;-) So I ask to see whether there is > something we can improve. Actually, this is not the point. 1) blocked load is more "difficult" to track, hint, migrate. 2) r(t1) - b(t2) is not anything, hint, t1 != t2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 6/7] sched: Provide runnable_load_avg back to cfs_rq
On Wed, Jul 15, 2015 at 08:04:41AM +0800, Yuyang Du wrote:
> The cfs_rq's load_avg is composed of runnable_load_avg and blocked_load_avg.
> Before this series, sometimes the runnable_load_avg is used, and sometimes
> the load_avg is used. Completely replacing all uses of runnable_load_avg
> with load_avg may be too big a leap, i.e., the blocked_load_avg is concerned
> to result in overrated load. Therefore, we get runnable_load_avg back.
>
> The new cfs_rq's runnable_load_avg is improved to be updated with all of the
> runnable sched_eneities at the same time, so the one sched_entity updated and
> the others stale problem is solved.
>
> Signed-off-by: Yuyang Du
> ---
> +/* Remove the runnable load generated by se from cfs_rq's runnable load
> average */
> +static inline void
> +dequeue_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se)
> +{
> + update_load_avg(se, 1);
> +
I think we need an update_cfs_rq_load_avg() here? Because the
runnable_load_avg may not be up to date when dequeue_entity_load_avg()
is called, right?
> + cfs_rq->runnable_load_avg =
> + max_t(long, cfs_rq->runnable_load_avg - se->avg.load_avg, 0);
> + cfs_rq->runnable_load_sum =
> + max_t(s64, cfs_rq->runnable_load_sum - se->avg.load_sum, 0);
> +}
> +
> /*
> * Task first catches up with cfs_rq, and then subtract
> * itself from the cfs_rq (task must be off the queue now).
> @@ -2982,7 +3015,7 @@ dequeue_entity(struct cfs_rq *cfs_rq, struct
> sched_entity *se, int flags)
>* Update run-time statistics of the 'current'.
>*/
> update_curr(cfs_rq);
> - update_load_avg(se, 1);
> + dequeue_entity_load_avg(cfs_rq, se);
>
> update_stats_dequeue(cfs_rq, se);
> if (flags & DEQUEUE_SLEEP) {
Thanks and Best Regards,
Boqun
signature.asc
Description: PGP signature
Re: [PATCH v10 6/7] sched: Provide runnable_load_avg back to cfs_rq
On Tue, Jul 21, 2015 at 06:18:46PM +0800, Boqun Feng wrote: > On Tue, Jul 21, 2015 at 08:44:01AM +0800, Yuyang Du wrote: > > On Tue, Jul 21, 2015 at 09:08:07AM +0800, Boqun Feng wrote: > > > Hi Yuyang, > > > > > > On Wed, Jul 15, 2015 at 08:04:41AM +0800, Yuyang Du wrote: > > > > The cfs_rq's load_avg is composed of runnable_load_avg and > > > > blocked_load_avg. > > > > Before this series, sometimes the runnable_load_avg is used, and > > > > sometimes > > > > the load_avg is used. Completely replacing all uses of runnable_load_avg > > > > with load_avg may be too big a leap, i.e., the blocked_load_avg is > > > > concerned > > > > to result in overrated load. Therefore, we get runnable_load_avg back. > > > > > > > > The new cfs_rq's runnable_load_avg is improved to be updated with all > > > > of the > > > > runnable sched_eneities at the same time, so the one sched_entity > > > > updated and > > > > the others stale problem is solved. > > > > > > > > > > How about tracking cfs_rq's blocked_load_avg instead of > > > runnable_load_avg, because, AFAICS: > > > > > > cfs_rq->runnable_load_avg = se->avg.load_avg - cfs_rq->blocked_load_avg. > > > > No, cfs_rq->runnable_load_avg = cfs_rq->avg.load_avg - > > cfs_rq->blocked_load_avg, > > without rounding errors and the like. > > > > Oh, sorry.. yeah, you're right here. > The point is that you have already tracked the sum of runnable_load_avg and blocked_load_avg in cfs_rq->avg.load_avg. If you're going to track part of the sum, you'd better track the one that's updated less frequently, right? Anyway, this idea just comes into my mind. I wonder which is udpated less frequently myself too. ;-) So I ask to see whether there is something we can improve. Regards, Boqun signature.asc Description: PGP signature
Re: [PATCH v10 6/7] sched: Provide runnable_load_avg back to cfs_rq
On Tue, Jul 21, 2015 at 08:44:01AM +0800, Yuyang Du wrote: > On Tue, Jul 21, 2015 at 09:08:07AM +0800, Boqun Feng wrote: > > Hi Yuyang, > > > > On Wed, Jul 15, 2015 at 08:04:41AM +0800, Yuyang Du wrote: > > > The cfs_rq's load_avg is composed of runnable_load_avg and > > > blocked_load_avg. > > > Before this series, sometimes the runnable_load_avg is used, and sometimes > > > the load_avg is used. Completely replacing all uses of runnable_load_avg > > > with load_avg may be too big a leap, i.e., the blocked_load_avg is > > > concerned > > > to result in overrated load. Therefore, we get runnable_load_avg back. > > > > > > The new cfs_rq's runnable_load_avg is improved to be updated with all of > > > the > > > runnable sched_eneities at the same time, so the one sched_entity updated > > > and > > > the others stale problem is solved. > > > > > > > How about tracking cfs_rq's blocked_load_avg instead of > > runnable_load_avg, because, AFAICS: > > > > cfs_rq->runnable_load_avg = se->avg.load_avg - cfs_rq->blocked_load_avg. > > No, cfs_rq->runnable_load_avg = cfs_rq->avg.load_avg - > cfs_rq->blocked_load_avg, > without rounding errors and the like. > Oh, sorry.. yeah, you're right here. > > se is the corresponding sched_entity of cfs_rq. And when we need the > > runnable_load_avg, we just calculate by the expression above. > > > > This can be thought as a lazy way to update runnable_load_avg, and we > > don't need to modify __update_load_avg any more. > > Not lazy at all, but adding (as of now) useless blocked_load_avg and an > extra subtraction. but we can remove runnable_load_avg tracking code in __update_load_avg, as you do in this patch, right? > Or did you forget blocked_load_avg also needs to be updated/decayed as > time elapses? I know we need to update or decay the blocked_load_avg, but we only need to update and decay when 1) entity dequeued/enqueued 2) entity migrated or 3) we need the runnable_load_avg value calcuated by blocked_load_avg, right? These are more rare than __update_load_avg called, right? Regards, Boqun signature.asc Description: PGP signature
Re: [PATCH v10 6/7] sched: Provide runnable_load_avg back to cfs_rq
On Tue, Jul 21, 2015 at 09:08:07AM +0800, Boqun Feng wrote: > Hi Yuyang, > > On Wed, Jul 15, 2015 at 08:04:41AM +0800, Yuyang Du wrote: > > The cfs_rq's load_avg is composed of runnable_load_avg and blocked_load_avg. > > Before this series, sometimes the runnable_load_avg is used, and sometimes > > the load_avg is used. Completely replacing all uses of runnable_load_avg > > with load_avg may be too big a leap, i.e., the blocked_load_avg is concerned > > to result in overrated load. Therefore, we get runnable_load_avg back. > > > > The new cfs_rq's runnable_load_avg is improved to be updated with all of the > > runnable sched_eneities at the same time, so the one sched_entity updated > > and > > the others stale problem is solved. > > > > How about tracking cfs_rq's blocked_load_avg instead of > runnable_load_avg, because, AFAICS: > > cfs_rq->runnable_load_avg = se->avg.load_avg - cfs_rq->blocked_load_avg. No, cfs_rq->runnable_load_avg = cfs_rq->avg.load_avg - cfs_rq->blocked_load_avg, without rounding errors and the like. > se is the corresponding sched_entity of cfs_rq. And when we need the > runnable_load_avg, we just calculate by the expression above. > > This can be thought as a lazy way to update runnable_load_avg, and we > don't need to modify __update_load_avg any more. Not lazy at all, but adding (as of now) useless blocked_load_avg and an extra subtraction. Or did you forget blocked_load_avg also needs to be updated/decayed as time elapses? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 6/7] sched: Provide runnable_load_avg back to cfs_rq
Hi Yuyang, On Wed, Jul 15, 2015 at 08:04:41AM +0800, Yuyang Du wrote: > The cfs_rq's load_avg is composed of runnable_load_avg and blocked_load_avg. > Before this series, sometimes the runnable_load_avg is used, and sometimes > the load_avg is used. Completely replacing all uses of runnable_load_avg > with load_avg may be too big a leap, i.e., the blocked_load_avg is concerned > to result in overrated load. Therefore, we get runnable_load_avg back. > > The new cfs_rq's runnable_load_avg is improved to be updated with all of the > runnable sched_eneities at the same time, so the one sched_entity updated and > the others stale problem is solved. > How about tracking cfs_rq's blocked_load_avg instead of runnable_load_avg, because, AFAICS: cfs_rq->runnable_load_avg = se->avg.load_avg - cfs_rq->blocked_load_avg. se is the corresponding sched_entity of cfs_rq. And when we need the runnable_load_avg, we just calculate by the expression above. This can be thought as a lazy way to update runnable_load_avg, and we don't need to modify __update_load_avg any more. Regards, Boqun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
