All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luca Abeni <luca.abeni@unitn.it>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	Juri Lelli <juri.lelli@arm.com>
Subject: Re: [RFC 4/8] Improve the tracking of active utilisation
Date: Thu, 28 Jan 2016 22:15:32 +0100	[thread overview]
Message-ID: <20160128221532.71a76bec@luca-1225C> (raw)
In-Reply-To: <20160128140053.GR6356@twins.programming.kicks-ass.net>

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!

  reply	other threads:[~2016-01-28 21:15 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-14 15:24 [RFC 0/8] CPU reclaiming for SCHED_DEADLINE Luca Abeni
2016-01-14 15:24 ` [RFC 1/8] Track the active utilisation Luca Abeni
2016-01-14 16:49   ` Peter Zijlstra
2016-01-15  6:37     ` Luca Abeni
2016-01-14 19:13   ` Peter Zijlstra
2016-01-15  8:07     ` Luca Abeni
2016-01-14 15:24 ` [RFC 2/8] Correctly track the active utilisation for migrating tasks Luca Abeni
2016-01-14 15:24 ` [RFC 3/8] sched/deadline: add some tracepoints Luca Abeni
2016-01-14 15:24 ` [RFC 4/8] Improve the tracking of active utilisation Luca Abeni
2016-01-14 17:16   ` Peter Zijlstra
2016-01-15  6:48     ` Luca Abeni
2016-01-14 19:43   ` Peter Zijlstra
2016-01-15  9:27     ` Luca Abeni
2016-01-19 12:20     ` Luca Abeni
2016-01-19 13:47       ` Peter Zijlstra
2016-01-27 13:36         ` Luca Abeni
2016-01-27 14:39           ` Peter Zijlstra
2016-01-27 14:45             ` Luca Abeni
2016-01-28 13:08               ` Vincent Guittot
     [not found]               ` <CAKfTPtAt0gTwk9aAZN238NT1O-zJvxVQDTh2QN_KxAnE61xMww@mail.gmail.com>
2016-01-28 13:48                 ` luca abeni
2016-01-28 13:56                   ` Vincent Guittot
2016-01-28 11:14             ` luca abeni
2016-01-28 12:21               ` Peter Zijlstra
2016-01-28 13:41                 ` luca abeni
2016-01-28 14:00                   ` Peter Zijlstra
2016-01-28 21:15                     ` Luca Abeni [this message]
2016-01-14 19:47   ` Peter Zijlstra
2016-01-15  8:10     ` Luca Abeni
2016-01-15  8:32       ` Peter Zijlstra
2016-01-14 15:24 ` [RFC 5/8] Track the "total rq utilisation" too Luca Abeni
2016-01-14 19:12   ` Peter Zijlstra
2016-01-15  8:04     ` Luca Abeni
2016-01-14 19:48   ` Peter Zijlstra
2016-01-15  6:50     ` Luca Abeni
2016-01-15  8:34       ` Peter Zijlstra
2016-01-15  9:15         ` Luca Abeni
2016-01-29 15:06           ` Peter Zijlstra
2016-01-29 21:21             ` Luca Abeni
2016-01-14 15:24 ` [RFC 6/8] GRUB accounting Luca Abeni
2016-01-14 19:50   ` Peter Zijlstra
2016-01-15  8:05     ` Luca Abeni
2016-01-14 15:24 ` [RFC 7/8] Make GRUB a task's flag Luca Abeni
2016-01-14 19:56   ` Peter Zijlstra
2016-01-15  8:15     ` Luca Abeni
2016-01-15  8:41       ` Peter Zijlstra
2016-01-15  9:08         ` Luca Abeni
2016-01-14 15:24 ` [RFC 8/8] Do not reclaim the whole CPU bandwidth Luca Abeni
2016-01-14 19:59   ` Peter Zijlstra
2016-01-15  8:21     ` Luca Abeni
2016-01-15  8:50       ` Peter Zijlstra
2016-01-15  9:49         ` Luca Abeni
2016-01-26 12:52         ` luca abeni
2016-01-27 14:44           ` Peter Zijlstra
2016-02-02 20:53             ` Luca Abeni
2016-02-03 11:30               ` Juri Lelli
2016-02-03 13:28                 ` luca abeni
2016-01-19 10:11 ` [RFC 0/8] CPU reclaiming for SCHED_DEADLINE Juri Lelli
2016-01-19 11:50   ` Luca Abeni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160128221532.71a76bec@luca-1225C \
    --to=luca.abeni@unitn.it \
    --cc=juri.lelli@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.