Messages in this thread | | | Date | Mon, 16 Jan 2023 11:33:26 +0100 | From | Peter Zijlstra <> | Subject | Re: [RFC PATCH v4 1/2] sched/fair: Introduce short duration task check |
| |
On Thu, Jan 05, 2023 at 12:33:16PM +0100, Dietmar Eggemann wrote: > On 16/12/2022 07:11, Chen Yu wrote: > > [...] > > > @@ -5995,6 +6005,18 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, int flags) > > > > static void set_next_buddy(struct sched_entity *se); > > > > +static inline void dur_avg_update(struct task_struct *p, bool task_sleep) > > +{ > > + u64 dur; > > + > > + if (!task_sleep) > > + return; > > + > > + dur = p->se.sum_exec_runtime - p->se.prev_sum_exec_runtime_vol; > > + p->se.prev_sum_exec_runtime_vol = p->se.sum_exec_runtime; > > Shouldn't se->prev_sum_exec_runtime_vol be set in enqueue_task_fair() > and not in dequeue_task_fair()->dur_avg_update()? Otherwise `dur` will > contain sleep time. > > Like we do for se->prev_sum_exec_runtime in set_next_entity() but for > one `set_next_entity()-put_prev_entity()` run section. > > AFAICS, you want to measure the exec_runtime sum over all run sections > between enqueue and dequeue.
You were thinking of the dynamic PELT window size thread? (which is what I had to think of when I looked at this).
I think we can still do that with this prev_sum_exec_runtime_vol (can't say I love the name though). At any point (assuming we update sum_exec_runtime) sum_exec_runtime - prev_sum_exec_runtime_vol is the duration of the current activation.
| |