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