Messages in this thread | | | Date | Wed, 16 Dec 2015 09:28:03 +0000 | From | Juri Lelli <> | Subject | Re: [RFCv6 PATCH 09/10] sched: deadline: use deadline bandwidth in scale_rt_capacity |
| |
Hi Luca,
On 15/12/15 22:24, Luca Abeni wrote: > On Tue, 15 Dec 2015 14:42:29 +0100 > Peter Zijlstra <peterz@infradead.org> wrote: > > On Tue, Dec 15, 2015 at 02:30:07PM +0100, Luca Abeni wrote: > > > > > >So I remember something else from the BFQ code, which also had to > > > >track entries for the 0-lag stuff, and I just had a quick peek at > > > >that code again. And what they appear to do is keep inactive > > > >entries with a lag deficit in a separate tree (the idle tree). > > > > > > > >And every time they update the vtime, they also push fwd the idle > > > >tree and expire entries on that. > > > I am not sure if I understand correctly the idea (I do not know the > > > BFQ code; I'll have a look), but I think I tried something similar: > > > - When a task blocks, instead of arming the inactive timer I can > > > insert the task in an "active non contending" tree (to use GRUB > > > terminology) > > > - So, when some sched deadline function is invoked, I check the > > > "0-lag time" of the first task in the "active non contending" tree, > > > and if that time is passed I remove the task from the tree and > > > adjust the active utilisation > > > > > > The resulting code ended up being more complex (basically, I needed > > > to handle the "active non contending" tree and to check it in > > > task_tick_dl() and update_curr_dl()). But maybe I did it wrong... > > > I'll try this approach again, after looking ad the BFQ code. > > > > That sounds about right. > > > > I've no idea if its more or less work. I just had vague memories on an > > alternative approach to the timer. > > > > Feel free to stick with the timer if that works better, just wanted to > > mention there are indeed alternative solutions. > Ok; I'll try to implement this alternative approach again, after > looking at BFQ, to see if it turns out to be simpler or more complex > than the timer-based approach. > > If there is interest, I'll send an RFC with these patches after some > testing. >
I think there's definitely interest, as next step will be to start using the new API for freq selection from DL as well.
Thanks a lot for your time and efforts!
Best,
- Juri
| |