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


Groups > linux.kernel > #1320687

Re: [RFC 4/8] Improve the tracking of active utilisation

From luca abeni <luca.abeni@unitn.it>
Newsgroups linux.kernel
Subject Re: [RFC 4/8] Improve the tracking of active utilisation
Date 2016-01-28 14:50 +0100
Message-ID <qVV7s-47l-17@gated-at.bofh.it> (permalink)
References (4 earlier) <qSEPw-8d-21@gated-at.bofh.it> <qVyue-49M-13@gated-at.bofh.it> <qVzqi-4RW-31@gated-at.bofh.it> <qVSMi-2B1-27@gated-at.bofh.it> <qVTS1-3iP-1@gated-at.bofh.it>
Organization university of trento

Show all headers | View raw


Hi Peter,

On Thu, 28 Jan 2016 13:21:00 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Thu, Jan 28, 2016 at 12:14:41PM +0100, luca abeni wrote:
> > I am looking at the PI stuff right now... And I am not sure if
> > SCHED_DEADLINE does the right thing for PI :)
> 
> Strictly speaking it does not, dl-pi is a giant hack.
> 
> Some day we should fix this :-)
I am trying to have a better look at the code, and I think that
implementing bandwidth inheritance (BWI) could be easy (implementing
M-BWI, that can be analyzed on multi-processor systems, is more complex
because it requires busy waiting or similar).


> But as you might be aware, SMP capable PI protocols for this are
> somewhat tricky.
Right :)


> > Anyway, I think the total SCHED_DEADLINE utilization (rd->dl_bw) is
> > currently not changed when a SCHED_OTHER task is boosted to
> > SCHED_DEADLINE due to PI... Right? 
> 
> From memory that is accurate, but not right as per the above. Ideally
> we would indeed charge the boosted task against the booster's
> bandwidth.
Yes, this would be the BWI approach


> This has the 'fun' consequence that while you deplete the bandwidth of
> the booster the PI order can change and we should pick another booster
> etc.
> 
> > Is this the desired behaviour?
> 
> Nope, but fixing this is likely to be non-trivial.
Ok... So, if this is acceptable for this patchset I'll try to keep the
current PI behaviour, and I'll try to have a look at a better PI
protocol after the runtime reclaiming stuff is done (that is, I make it
acceptable for mainline, or we decide that a different approach is
needed).



			Luca

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


Thread

Re: [RFC 4/8] Improve the tracking of active utilisation luca abeni <luca.abeni@unitn.it> - 2016-01-28 12:20 +0100
  Re: [RFC 4/8] Improve the tracking of active utilisation Peter Zijlstra <peterz@infradead.org> - 2016-01-28 13:30 +0100
    Re: [RFC 4/8] Improve the tracking of active utilisation luca abeni <luca.abeni@unitn.it> - 2016-01-28 14:50 +0100
      Re: [RFC 4/8] Improve the tracking of active utilisation Peter Zijlstra <peterz@infradead.org> - 2016-01-28 15:10 +0100
        Re: [RFC 4/8] Improve the tracking of active utilisation Luca Abeni <luca.abeni@unitn.it> - 2016-01-28 22:20 +0100

csiph-web