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


Groups > linux.kernel > #1342461

Re: [PATCH 1/2] sched/deadline: add per rq tracking of admitted bandwidth

From luca abeni <luca.abeni@unitn.it>
Newsgroups linux.kernel
Subject Re: [PATCH 1/2] sched/deadline: add per rq tracking of admitted bandwidth
Date 2016-02-24 22:50 +0100
Message-ID <r5PtN-2bk-13@gated-at.bofh.it> (permalink)
References (6 earlier) <r0Zar-NF-21@gated-at.bofh.it> <r10pQ-1zg-17@gated-at.bofh.it> <r12UG-3l3-23@gated-at.bofh.it> <r1poe-1rA-1@gated-at.bofh.it> <r5N8C-zJ-25@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Hi,

On Wed, 24 Feb 2016 20:17:52 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Fri, Feb 12, 2016 at 06:05:30PM +0100, Peter Zijlstra wrote:
> > Having two separate means of accounting this also feels more fragile
> > than one would want.
> > 
> > Let me think a bit about this.
> 
> I think there's a fundamental problem that makes the whole notion of
> per-rq accounting 'impossible'.
> 
> On hot-unplug we only migrate runnable tasks, all blocked tasks remain
> on the dead cpu. This would very much include their bandwidth
> requirements.
> 
> This means that between a hot-unplug and the moment that _all_ those
> blocked tasks have ran at least once, the sum of online bandwidth
> doesn't match and we can get into admission trouble (same for GRUB,
> which can also use per-rq bw like this).

After Juri's patch and emails, I tried to think about the CPU
hot-(un)plugging issues, and to check if/how they affect GRUB
reclaiming...

I arrived to the conclusion that for GRUB this is not a problem (but,
as usual, I might be wrong): GRUB just needs to track the per-runqueue
active/inactive utilization, and is not badly affected by the fact that
inactive utilization is migrated "too late" (when a task wakes up
instead of when the CPU goes offline). This is because GRUB does not
care about "global" utilization, but considers the various runqueues in
isolation (there is a flavor of the m-grub algorithm that uses global
inactive utilization, but it is not implemented by the patches I
submitted).
In other words: Juri's patch uses per-runqueue utilizations to re-build
the global utilization, while GRUB does not care if the sum of the
"active utilizations" match with the utilization used for admission
control.

I still have to check some details, and to run some more tests with CPU
hot-(un)plug (and this is why I did not send a v2 of the reclaiming RFC
yet)... In particular, I need to check what happens if the "inactive
timer" fires when the CPU on which the task was running is already
offline.



			Thanks,
				Luca

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


Thread

Re: [PATCH 1/2] sched/deadline: add per rq tracking of admitted  bandwidth Peter Zijlstra <peterz@infradead.org> - 2016-02-24 20:20 +0100
  Re: [PATCH 1/2] sched/deadline: add per rq tracking of admitted  bandwidth luca abeni <luca.abeni@unitn.it> - 2016-02-24 22:50 +0100
    Re: [PATCH 1/2] sched/deadline: add per rq tracking of admitted  bandwidth Peter Zijlstra <peterz@infradead.org> - 2016-02-25 09:00 +0100
  Re: [PATCH 1/2] sched/deadline: add per rq tracking of admitted  bandwidth Juri Lelli <juri.lelli@arm.com> - 2016-02-25 11:10 +0100
    Re: [PATCH 1/2] sched/deadline: add per rq tracking of admitted  bandwidth Peter Zijlstra <peterz@infradead.org> - 2016-02-25 11:30 +0100

csiph-web