Messages in this thread | | | Date | Mon, 3 Jul 2023 10:19:17 -0400 | From | Phil Auld <> | Subject | Re: [PATCH v4] Sched/fair: Block nohz tick_stop when cfs bandwidth in use |
| |
On Mon, Jul 03, 2023 at 10:10:56AM -0400 Phil Auld wrote: > On Mon, Jul 03, 2023 at 02:10:09PM +0200 Peter Zijlstra wrote: > > On Fri, Jun 30, 2023 at 12:29:10PM -0400, Phil Auld wrote: > > > > > I think you are agreeing that I need the pick next code but need to remove > > > the hierarchy walks, right? > > > > Yeah, the dequeue case makes we have to care about pick, not sure we > > then also need to care about sched_update_tick_dependency() though. > > There is indeed a window where these two will 'race', but afaict it is > > benign. > > > > Hm, that's confusing. > > As I see it it's the enqueue case (0->1 mostly) where we need the check > in pick. At that point in enqueue we only have a handle on ->curr which > is the idle thread. > > For the dequeue case (2->1) we need the check in the > sched_update_tick_dependency() path because if the 1 is the task on the > cpu (and is staying there) then we'd otherwise clear the bit when we > shouldn't (since we aren't going to go back through pick). >
And, for clarity, the "bit" in that case is TICK_DEP_BIT_SCHED not the new task::bw_constrained field. I.e. we'll endup allowing the tick to stop for a bw limited task and thus not solve the problem.
> I'm thinking that I'll try to set the bit in pick since we only care about > it when it's the task on the cpu. That, I think, will simplify the > code needed to update the bit when the quota is changed (to or from > RUNTIME_INF). > > Setting the bit in enqueue/dequeue means updating it on all the queued > task if it changes. Although I may clear it in dequeue just to not leave > it around stale. > > > Cheers, > Phil > -- >
--
| |