Path: csiph.com!news.mixmin.net!aioe.org!bofh.it!news.nic.it!robomod
From: Luca Abeni <luca.abeni@unitn.it>
Newsgroups: linux.kernel
Subject: Re: [RFC 4/8] Improve the tracking of active utilisation
Date: Thu, 28 Jan 2016 22:20:02 +0100
Message-ID: <qW28W-R2-23@gated-at.bofh.it>
References: <qQS0x-uX-3@gated-at.bofh.it> <qQS0x-uX-9@gated-at.bofh.it> <qQW4a-3gr-23@gated-at.bofh.it> <qSDA5-7Pd-13@gated-at.bofh.it> <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> <qVV7s-47l-17@gated-at.bofh.it> <qVVqP-4wq-15@gated-at.bofh.it>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: robomod@news.nic.it
Approved: robomod@news.nic.it
Lines: 47
Organization: linux.* mail to news gateway
Xref: csiph.com linux.kernel:1321066

On Thu, 28 Jan 2016 15:00:53 +0100
Peter Zijlstra <peterz@infradead.org> wrote:
> On Thu, Jan 28, 2016 at 02:41:29PM +0100, luca abeni wrote:
> 
> > > 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).
> 
> Ah indeed, I remember now. To which I said that if busy-waiting is
> 'correct' so then must not busy-waiting be, for that consumes less
> cputime and would allow more actual work to be done.
The issue is that when the task wakes up after blocking, the scheduler
has to check if the current deadline and runtime can still be used (and
if they cannot, it generates a new deadline).
Of course a blocking solution can work, but the strategy used to check
if deadline and runtime are still valid must be changed. I discussed
this with the M-BWI authors about one year ago, but we did not arrive
to a definitive conclusion.

Anyway, I suspect that implementing BWI (without the "M-"), which has
no busy-waiting, could be an improvement respect to the current
mechanism.


			Thanks,
				Luca

> 
> Of course, I might have missed some subtle detail, but intuition
> suggests the above.
> 
> > > 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,
> 
> Yeah that's fine. That's decidedly outside the scope of these patches.
> 
> > 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).
> 
> That would be very nice indeed!