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


Groups > linux.kernel > #1609970

Re: [RFC v5 8/9] sched/deadline: base GRUB reclaiming on the inactive utilization

From Peter Zijlstra <peterz@infradead.org>
Newsgroups linux.kernel
Subject Re: [RFC v5 8/9] sched/deadline: base GRUB reclaiming on the inactive utilization
Date 2017-03-27 18:20 +0200
Message-ID <tpFx7-2mb-15@gated-at.bofh.it> (permalink)
References <toh3P-72e-5@gated-at.bofh.it> <toh3P-72e-13@gated-at.bofh.it> <tpDOF-Ur-3@gated-at.bofh.it> <tpEhI-17e-23@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Mon, Mar 27, 2017 at 04:56:51PM +0200, Luca Abeni wrote:

> > > +u64 grub_reclaim(u64 delta, struct rq *rq, u64 u)
> > >  {
> > > +	u64 u_act;
> > > +
> > > +	if (rq->dl.this_bw - rq->dl.running_bw > (1 << 20) - u)
> > > +		u_act = u;
> > > +	else
> > > +		u_act = (1 << 20) - rq->dl.this_bw +
> > > rq->dl.running_bw; +
> > > +	return (delta * u_act) >> 20;  
> > 
> > But that's not what is done here I think, something like this instead:
> > 
> > 	Uinact = Utot - Uact
> > 
> > 		-t_u dt ; Uinact > (1 - t_u)
> > 	dq = {
> > 		-(1 - Uinact) dt
> > 
> > 
> > And nowhere do we have an explanation for that.
> 
> Sorry about this confusion... The accounting should be
> 	dq = -(1 - Uinact)dt
> but if (1 - Uinact) is too large (larger than the task's utilization)
> then we use the task's utilization instead (otherwise, we end up
> reclaiming other runqueues' time). I realized that this check was
> needed after writing the comments, and I forgot to update the comments
> when I fixed the code :(
> 
> > Now, I suspect we can write that like: dq = -max{ t_u, (1 - Uinact) }
> > dt, which would suggest this is a sanity check on Utot, which I
> > suspect can be over 1. Is this what is happening?
> 
> Right... I'll fix the code and comments according to your suggestion.

But doesn't that suggest there is now another corner case where we
'always' select t_u because of Utot overload?

My intuition suggests we'd reclaim insufficient time in that case, but
I've not thought much about it.

I feel we want a few words explaining the trade-offs made here and the
corner cases explored.

Does that make sense?

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


Thread

[RFC v5 0/9] CPU reclaiming for SCHED_DEADLINE  luca abeni <luca.abeni@santannapisa.it> - 2017-03-23 21:00 +0100
  [RFC v5 8/9] sched/deadline: base GRUB reclaiming on the inactive utilization luca abeni <luca.abeni@santannapisa.it> - 2017-03-23 21:00 +0100
    Re: [RFC v5 8/9] sched/deadline: base GRUB reclaiming on the  inactive utilization Peter Zijlstra <peterz@infradead.org> - 2017-03-27 16:30 +0200
      Re: [RFC v5 8/9] sched/deadline: base GRUB reclaiming on the  inactive utilization Luca Abeni <luca.abeni@santannapisa.it> - 2017-03-27 17:00 +0200
        Re: [RFC v5 8/9] sched/deadline: base GRUB reclaiming on the  inactive utilization Peter Zijlstra <peterz@infradead.org> - 2017-03-27 18:20 +0200
          Re: [RFC v5 8/9] sched/deadline: base GRUB reclaiming on the  inactive utilization luca abeni <luca.abeni@santannapisa.it> - 2017-03-27 19:10 +0200
  [RFC v5 2/9] sched/deadline: improve the tracking of active utilization luca abeni <luca.abeni@santannapisa.it> - 2017-03-23 21:00 +0100
    Re: [RFC v5 2/9] sched/deadline: improve the tracking of active  utilization Peter Zijlstra <peterz@infradead.org> - 2017-03-24 14:30 +0100
    Re: [RFC v5 2/9] sched/deadline: improve the tracking of active  utilization Peter Zijlstra <peterz@infradead.org> - 2017-03-24 14:30 +0100
      Re: [RFC v5 2/9] sched/deadline: improve the tracking of active  utilization luca abeni <luca.abeni@santannapisa.it> - 2017-03-24 22:50 +0100
        Re: [RFC v5 2/9] sched/deadline: improve the tracking of active  utilization Steven Rostedt <rostedt@goodmis.org> - 2017-03-25 03:40 +0100
          Re: [RFC v5 2/9] sched/deadline: improve the tracking of active  utilization Luca Abeni <luca.abeni@santannapisa.it> - 2017-03-27 10:30 +0200
            Re: [RFC v5 2/9] sched/deadline: improve the tracking of active utilization Claudio Scordino <claudio@evidence.eu.com> - 2017-03-27 11:00 +0200
        Re: [RFC v5 2/9] sched/deadline: improve the tracking of active  utilization Juri Lelli <juri.lelli@arm.com> - 2017-03-27 09:20 +0200
          Re: [RFC v5 2/9] sched/deadline: improve the tracking of active  utilization Luca Abeni <luca.abeni@santannapisa.it> - 2017-03-27 10:10 +0200
            Re: [RFC v5 2/9] sched/deadline: improve the tracking of active  utilization Juri Lelli <juri.lelli@arm.com> - 2017-03-27 10:50 +0200
        Re: [RFC v5 2/9] sched/deadline: improve the tracking of active  utilization Luca Abeni <luca.abeni@santannapisa.it> - 2017-03-27 09:40 +0200
    Re: [RFC v5 2/9] sched/deadline: improve the tracking of active utilization Mathieu Poirier <mathieu.poirier@linaro.org> - 2017-03-26 19:40 +0200
      Re: [RFC v5 2/9] sched/deadline: improve the tracking of active  utilization luca abeni <luca.abeni@santannapisa.it> - 2017-03-26 23:10 +0200
  [RFC v5 6/9] sched/deadline: make GRUB a task's flag luca abeni <luca.abeni@santannapisa.it> - 2017-03-23 21:00 +0100
  [RFC v5 7/9] sched/deadline: track the "total rq utilization" too luca abeni <luca.abeni@santannapisa.it> - 2017-03-23 21:00 +0100
  [RFC v5 4/9] sched/deadline: implement GRUB accounting luca abeni <luca.abeni@santannapisa.it> - 2017-03-23 21:00 +0100
  [RFC v5 3/9] sched/deadline: fix the update of the total -deadline utilization luca abeni <luca.abeni@santannapisa.it> - 2017-03-23 21:00 +0100

csiph-web