Messages in this thread | | | From | Vincent Guittot <> | Date | Mon, 27 Feb 2023 18:15:15 +0100 | Subject | Re: [PATCH v3] sched/fair: sanitize vruntime of entity being placed |
| |
On Mon, 27 Feb 2023 at 18:00, Dietmar Eggemann <dietmar.eggemann@arm.com> wrote: > > On 27/02/2023 15:37, Vincent Guittot wrote: > > On Mon, 27 Feb 2023 at 09:43, Roman Kagan <rkagan@amazon.de> wrote: > >> > >> On Tue, Feb 21, 2023 at 06:26:11PM +0100, Vincent Guittot wrote: > >>> On Tue, 21 Feb 2023 at 17:57, Roman Kagan <rkagan@amazon.de> wrote: > >>>> What scares me, though, is that I've got a message from the test robot > >>>> that this commit drammatically affected hackbench results, see the quote > >>>> below. I expected the commit not to affect any benchmarks. > >>>> > >>>> Any idea what could have caused this change? > >>> > >>> Hmm, It's most probably because se->exec_start is reset after a > >>> migration and the condition becomes true for newly migrated task > >>> whereas its vruntime should be after min_vruntime. > >>> > >>> We have missed this condition > >> > >> Makes sense to me. > >> > >> But what would then be the reliable way to detect a sched_entity which > >> has slept for long and risks overflowing in .vruntime comparison? > > > > For now I don't have a better idea than adding the same check in > > migrate_task_rq_fair() > > Don't we have the issue that we could have a non-up-to-date rq clock in > migrate? No rq lock held in `!task_on_rq_migrating(p)`.
yes the rq clock may be not up to date but that would also mean that the cfs was idle and as a result its min_vruntime has not moved forward and we don't have a problem of possible overflow
> > Also deferring `se->exec_start = 0` from `migrate` into `enqueue -> > place entity` doesn't seem to work since the rq clocks of different CPUs > are not in sync.
yes
>
| |