Date:   Tue, 31 Jan 2023 11:21:17 +0800
From:   Chen Yu <yu.c.chen@intel.com>
To:     Vincent Guittot <vincent.guittot@linaro.org>
CC:     Peter Zijlstra <peterz@infradead.org>,
        Roman Kagan <rkagan@amazon.de>,
        Zhang Qiao <zhangqiao22@huawei.com>,
        Waiman Long <longman@redhat.com>,
        "Ingo Molnar" <mingo@redhat.com>,
        Juri Lelli <juri.lelli@redhat.com>,
        "Dietmar Eggemann" <dietmar.eggemann@arm.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
        "Daniel Bristot de Oliveira" <bristot@redhat.com>,
        lkml <linux-kernel@vger.kernel.org>
Subject: Re: [bug-report] possible s64 overflow in max_vruntime()
Message-ID: <Y9iJLQxyXp9+x2aF@chenyu5-mobl1>
References: <73e639d5-702b-0d03-16d9-a965b1963ef6@huawei.com>
 <Y6RRfF5yRew7rdCp@hirez.programming.kicks-ass.net>
 <Y9GG3N5ivVvyETa2@u40bc5e070a0153.ant.amazon.com>
 <Y9J25xMrItpeHIxD@hirez.programming.kicks-ass.net>
 <Y9LG5vkf/4ufJb35@u40bc5e070a0153.ant.amazon.com>
 <Y9O5Fwfib2CVAMwl@hirez.programming.kicks-ass.net>
 <CAKfTPtBMSg2SDXq=sVt99TyM+tEXRFL74EQ57-t5uKYAXUUyLg@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAKfTPtBMSg2SDXq=sVt99TyM+tEXRFL74EQ57-t5uKYAXUUyLg@mail.gmail.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?BoRD+R3pxDIoiDFL8nVqZgYpglQgDUbnnXG2kK2Ma8jvMh1Im+GPHEmqkuLC?=
 =?us-ascii?Q?QPCAnSCuEDO3eGfnzqF39tdfydUVdP6EAuaaaFea4zdkRhbd91RUFmqFOcAf?=
 =?us-ascii?Q?Teml17EnHDUI0nIUnw0o0mPEbNFnO6UfUOagpqroQDg4uBpkvjO53Tp8b6J2?=
 =?us-ascii?Q?tw6PgxEw17pVfFyEBBNnXnGK+SNL+/enmGumebakMjjhyts1gYxoKyXlk0Vy?=
 =?us-ascii?Q?Oicc+tQN129eOk4mswrpNZCxbuqTgb2r/jMPgN3/8t++7DtS1NafqD2HTw47?=
 =?us-ascii?Q?IBPRdlMg3I1nlheV8/uk/fEbtWM5iZenqFGARdKbVigg1qz9utBKFvrEcAHx?=
 =?us-ascii?Q?phH/59h3dma8XdYaybVOHINqiLttM+2tIju1BeFn2S+l7KFm7ciwoejfxw00?=
 =?us-ascii?Q?gJ3fpYT7kHXHbRstX6ki38/vsRp3gcP6nqgEHmNoP1THhciMTp9Bi1A+g21v?=
 =?us-ascii?Q?z/6dWoixxxBHgksS33ndTfBbKm9peel6H+op2H+QSX5mfm4oGIV7tJVtaSsi?=
 =?us-ascii?Q?9At/Lf3Rh4SbXroqzOiyZfeJjpZQmr6DIXz8w/HEwK35eS7/Fc3SPveL/MBy?=
 =?us-ascii?Q?XJfBlnEI9QFktBiKd9vFO/GBY9vWoqTIyuKe3deQDrfeSg7jZGJgkxhRI6JN?=
 =?us-ascii?Q?txkxoBImzLHNgCfA6XfR4TA0OjZ4nm9a2hvxVHk2m8QLYoeR3MvOwFTm4HCm?=
 =?us-ascii?Q?6w1BCWIb0KO28Y4xVYY7BPUGdgtTEw5wq/fuFevgorrgAjQBc8rqJLTu610Y?=
 =?us-ascii?Q?+LmXGKxQGW37PT5eFnba4Z6egHIowY+Js3n0BYQ1hl3cGoVi2ARrPA+PU1QQ?=
 =?us-ascii?Q?T3samqSdROJKLOlm1mXUj5K5YVAj6o58BYJtKBk77LORFkSy4Uk8mIiourvL?=
 =?us-ascii?Q?QymFvf4/et6egJaUGJsdmt9DLLbyoKLx/xfcP9z1Hq6PQaJQRx4WM97IV4Iv?=
 =?us-ascii?Q?LMJRJU09+1uT1dzq9q8h60rgoU5y5o53uokxd0ONlRooSSO49ZOv1qNMscLC?=
 =?us-ascii?Q?PfWdP9xsSkzMyEu2Uoc1ryX6eArBmDhFEsGOC5CpNi01L82xMQ6AcfrfD5er?=
 =?us-ascii?Q?K6ya8CpLifTSiwrq/5kwR063xvF5PPG/QnJtcTQyqQW2kMF5Spt3IQyhIVGP?=
 =?us-ascii?Q?zgQncpOJILzbBt2WcALiiXz3rK1KUmi48FYmK5ssTTCL3gO+hkJzWPsVte95?=
 =?us-ascii?Q?I9l7a58D/DxmmhB9Ndm10SDuyjdHNBcVKVR+dwoKNZdX6HZtkoVCJbTr2hyq?=
 =?us-ascii?Q?TOCauuR0HNSF01xQAIDJiaofOsy2WUc0PffrZrGRcJrEoNOZwMoAD888gBiN?=
 =?us-ascii?Q?OQ8lsoODBF1wpdZLOO5WohdtRXwjDY9qhHtxpAJdaIP4yIl2Ft/ldYdttpOJ?=
 =?us-ascii?Q?Q0+gxjo+wu0SPNFWBPzUD7mGYfmemIgkOGsyRvfsLgTrBFzZY8gDEX+ByMp8?=
 =?us-ascii?Q?lk88G4EAc2AHPEWeR0jJkXpc8461j3CCoBEM7d8TQlCYT636V66lLaWe7EtG?=
 =?us-ascii?Q?N+QnaVUa6BvfVETvq2ZOPYa+A0mErbgJ1vVU4/mfDWrkmcP+4S6DoR0uPPHL?=
 =?us-ascii?Q?lx4urJOdnq0iGchikJalqQRMUQFLIVYtVpIk39qm?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 1f75f100-adcf-4e77-e2c0-08db033a4306
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6206.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jan 2023 03:21:37.4630
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ToOzPpPQiRLc9XOYYBp8F+oeWOBeqXUTRn8/a7mY6yLgP6HnTFl4kp2NA0I1OtalcNkF++44msydSLPem1idvw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR11MB5219
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2023-01-27 at 17:18:56 +0100, Vincent Guittot wrote:
> On Fri, 27 Jan 2023 at 12:44, Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Thu, Jan 26, 2023 at 07:31:02PM +0100, Roman Kagan wrote:
> >
> > > > All that only matters for small sleeps anyway.
> > > >
> > > > Something like:
> > > >
> > > >         sleep_time = U64_MAX;
> > > >         if (se->avg.last_update_time)
> > > >           sleep_time = cfs_rq_clock_pelt(cfs_rq) - se->avg.last_update_time;
> > >
> > > Interesting, why not rq_clock_task(rq_of(cfs_rq)) - se->exec_start, as
> > > others were suggesting?  It appears to better match the notion of sleep
> > > wall-time, no?
> >
> > Should also work I suppose. cfs_rq_clock takes throttling into account,
> > but that should hopefully also not be *that* long, so either should
> > work.
> 
> yes rq_clock_task(rq_of(cfs_rq)) should be fine too
> 
> Another thing to take into account is the sleeper credit that the
> waking task deserves so the detection should be done once it has been
> subtracted from vruntime.
> 
> Last point, when a nice -20 task runs on a rq, it will take a bit more
> than 2 seconds for the vruntime to be increased by more than 24ms (the
> maximum credit that a waking task can get) so threshold must be
> significantly higher than 2 sec. On the opposite side, the lowest
> possible weight of a cfs rq is 2 which means that the problem appears
> for a sleep longer or equal to 2^54 = 2^63*2/1024. We should use this
> value instead of an arbitrary 200 days
Does it mean any threshold between 2 sec and 2^54 nsec should be fine? Because
1. Any task sleeps longer than 2 sec will get at most 24 ms(sysctl_sched_latency)
   'vruntime bonus' when enqueued.
2. Although a low weight cfs rq run for 2^54 nsec could trigger the overflow,
   we can choose threshold lower than 2^54 to avoid any overflow.

thanks,
Chenyu