Messages in this thread | | | From | Benjamin Segall <> | Subject | Re: [RFC PATCH v2 0/5] sched/fair: Defer CFS throttle to user entry | Date | Tue, 06 Feb 2024 13:55:02 -0800 |
| |
Valentin Schneider <vschneid@redhat.com> writes:
> Proposed approach > ================= > > Peter mentioned [1] that there have been discussions on changing /when/ the > throttling happens: rather than have it be done immediately upon updating > the runtime statistics and realizing the cfs_rq has depleted its quota, we wait > for the task to be about to return to userspace: if it's in userspace, it can't > hold any in-kernel lock. > > I submitted an initial jab at this [2] and Ben Segall added his own version to > the conversation [3]. This series contains Ben's patch plus my additions. The > main change here is updating the .h_nr_running counts throughout the cfs_rq > hierachies to improve the picture given to load_balance(). > > The main thing that remains doing for this series is making the second cfs_rq > tree an actual RB tree (it's just a plain list ATM). > > This also doesn't touch rq.nr_running yet, I'm not entirely sure whether we want > to expose this outside of CFS, but it is another field that's used by load balance.
Then there's also all the load values as well; I don't know the load balance code well, but it looks like the main thing would be runnable_avg and that it isn't doing anything that would particularly care about h_nr_running and runnable_avg being out of sync.
Maybe pulling a pending-throttle user task and then not seeing the update in h_nr_running could be a bit of trouble?
| |