Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1320687
| 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 |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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