[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y/xtDWYTKLutOqrM@u40bc5e070a0153.ant.amazon.com>
Date: Mon, 27 Feb 2023 09:42:54 +0100
From: Roman Kagan <rkagan@...zon.de>
To: Vincent Guittot <vincent.guittot@...aro.org>
CC: Peter Zijlstra <peterz@...radead.org>,
<linux-kernel@...r.kernel.org>,
Valentin Schneider <vschneid@...hat.com>,
Zhang Qiao <zhangqiao22@...wei.com>,
Ben Segall <bsegall@...gle.com>,
Waiman Long <longman@...hat.com>,
Steven Rostedt <rostedt@...dmis.org>,
Mel Gorman <mgorman@...e.de>,
Dietmar Eggemann <dietmar.eggemann@....com>,
"Daniel Bristot de Oliveira" <bristot@...hat.com>,
Ingo Molnar <mingo@...hat.com>,
Juri Lelli <juri.lelli@...hat.com>
Subject: Re: [PATCH v3] sched/fair: sanitize vruntime of entity being placed
On Tue, Feb 21, 2023 at 06:26:11PM +0100, Vincent Guittot wrote:
> On Tue, 21 Feb 2023 at 17:57, Roman Kagan <rkagan@...zon.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?
Thanks,
Roman.
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
Powered by blists - more mailing lists