Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1192645

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

From Boqun Feng <boqun.feng@gmail.com>
Newsgroups linux.kernel
Subject Re: [PATCH v10 6/7] sched: Provide runnable_load_avg back to cfs_rq
Date 2015-07-27 06:10 +0200
Message-ID <pQHTI-7bD-11@gated-at.bofh.it> (permalink)
References (4 earlier) <pOCOt-5nc-11@gated-at.bofh.it> <pOD7Q-5JB-25@gated-at.bofh.it> <pQGuB-54l-1@gated-at.bofh.it> <pQHgZ-6dy-1@gated-at.bofh.it> <pQHAl-6zT-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

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

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH v10 6/7] sched: Provide runnable_load_avg back to cfs_rq Boqun Feng <boqun.feng@gmail.com> - 2015-07-27 05:30 +0200
  Re: [PATCH v10 6/7] sched: Provide runnable_load_avg back to cfs_rq Boqun Feng <boqun.feng@gmail.com> - 2015-07-27 05:40 +0200
  Re: [PATCH v10 6/7] sched: Provide runnable_load_avg back to cfs_rq Yuyang Du <yuyang.du@intel.com> - 2015-07-27 05:50 +0200
    Re: [PATCH v10 6/7] sched: Provide runnable_load_avg back to cfs_rq Boqun Feng <boqun.feng@gmail.com> - 2015-07-27 06:10 +0200
      Re: [PATCH v10 6/7] sched: Provide runnable_load_avg back to cfs_rq Yuyang Du <yuyang.du@intel.com> - 2015-07-27 06:30 +0200

csiph-web