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

Groups > linux.kernel > #1320571 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

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

Hi Peter,

On Wed, 27 Jan 2016 15:39:46 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, Jan 27, 2016 at 02:36:51PM +0100, Luca Abeni wrote:
> > Ok, so I implemented this idea, and I am currently testing it...
> > The first experiments seem to show that there are no problems, but I
> > just tried some simple workload (rt-app, or some other periodic
> > taskset scheduled by SCHED_DEADLINE). Do you have suggestions for
> > more "interesting" (and meaningful) tests/experiments?
> 
> rt-app is the workload generator, right?
> 
> I think the most interesting part here is the switched_from path, so
> you'd want the workload to include a !rt task that gets PI boosted to
> deadline every so often.
I am looking at the PI stuff right now... And I am not sure if
SCHED_DEADLINE does the right thing for PI :)

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? Is this the desired behaviour?
If yes, I'll make sure that my patch does not change it.



			Thanks,
				Luca

[toc] | [next] | [standalone]

#1320618

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 :-)

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

> 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.

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.

[toc] | [prev] | [next] | [standalone]

#1320687

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

[toc] | [prev] | [next] | [standalone]

#1320710

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.

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!

[toc] | [prev] | [next] | [standalone]

#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!

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web