Messages in this thread | | | Date | Fri, 30 Jun 2023 12:29:10 -0400 | From | Phil Auld <> | Subject | Re: [PATCH v4] Sched/fair: Block nohz tick_stop when cfs bandwidth in use |
| |
On Fri, Jun 30, 2023 at 06:05:34PM +0200 Peter Zijlstra wrote: > On Fri, Jun 30, 2023 at 11:28:24AM -0400, Phil Auld wrote: > > > No. Or at least not without plumbing the enqueued/dequeued task all the way > > through. I can do it that way if you prefer but that seemed a lot more > > intrusive. When we are in sched_can_stop_tick() we don't have access to the > > cfs task which will end up running. Curr is idle in that case. We'd have to > > essential run pick_next_task_fair() to find the task to check which seemed > > wrong. Maybe there is a better way? > > Ah, you worry about where we have two runnable tasks, one is bandwidth > constrained the other is not. One task goes away, how can we tell what > the remaining task is?
It didn't even have to be an unconstrained task before I added the check in sched_can_stop_tick(). But yes that check catches the case where the one (still) running task is bw constrained.
> > This is never a concern for add_nr_running(), the only case there is > 0->1 and then only the hierarchy you just walked for enqueue is > relevant. >
Right but we don't (currently) have the task here (hence the pick_next code).
> But if you remove the unconstrained task, sub_nr_running() can't tell > what the remaining task is. > > Unless, of course, you have enqueue() set a bit somewhere in > task_struct::sched_bw_constrained:1. > > Then pick and your should_stop thing can look at that, no? >
Yes.
I think you are agreeing that I need the pick next code but need to remove the hierarchy walks, right?
If I set the bit in task_struct it would do that. I'll go poke at that.
Thanks, Phil
--
| |