Re: [PATCH v10 6/7] sched: Provide runnable_load_avg back to cfs_rq

[Boqun Feng <boqun.feng@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3252 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]