On 06/11/25 18:09, Andrea Righi wrote: > On Thu, Nov 06, 2025 at 10:49:20AM +0100, Juri Lelli wrote: > > Hi, > > > > On 29/10/25 20:08, Andrea Righi wrote: > > > During switching from sched_ext to fair tasks and vice-versa, we need > > > support for intializing and removing the bandwidth contribution of > > > either DL server. > > > > My first and more general/design question is do we strictly need this > > automagic bandwidth management. We seem to agree [1] that we want to > > move towards explicit dl-server(s) and tasks bandwidth handling, so we > > might want to consider leaving the burden completely to whomever might > > be configuring the system. > > I think we decided to take this approach because, once a sched_ext > scheduler is loaded and all tasks are moved to the ext class, the fair > class becomes "empty", but the fair dl-server would still keep its > bandwidth reserved, so somehow we need to release that reservation, > right?
Right. I was just alluding to the fact that keeping the "empty" fair_server reservations is not wrong, but indeed sub-optimal. I didn't want to block this series if we don't get the automagical removal right, so wondered if it could be left for later (as we will still have a manual way to remove the empty reservations anyway :). ... > > > + > > > + hrtimer_cancel(&dl_se->inactive_timer); > > > > I am not sure we actually need to force cancel the timer (but still > > contradicting myself every time I go back at staring at code :). The way > > I believe this should work 'in theory' is > > > > - we remove a server (either automagic or user sets runtime to 0 - > > which is probably to fix/look at in current implementation as well > > btw) > > - current bandwidth is retained and only freed (and server reset) at > > 0-lag (when inactive_timer fires) > > - if server is activated back before 0-lag it will use it's current > > parameters > > - after 0-lag it's a new instance with new parameters > > Hm... that means just setting the runtime to 0 IIUC. I think I tried that > approach in the past, but I was seeing some inconsistencies with the > total_bw kselftest, starting/stopping an scx scheduler multiple times > seemed to gradually consume all the available bandwidth. > > But I can give it another try, maybe that behavior was caused by other > issues, since we've fixed quite a few things since then. Or maybe it could be inactive_timer/dl_non_contending handling that still has some problems. Anyway, I noticed that it is still possible to write runtime values of fair_server while/after scx_server took over. Those values get overridden when scx_server switches off. Guess we want to prevent writes while scx_server has full control?
