From: Peter Zijlstra <peterz@infradead.org>
To: zhengzucheng <zhengzucheng@huawei.com>
Cc: mingo@redhat.com, juri.lelli@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
vschneid@redhat.com, oleg@redhat.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH -next] sched/cputime: Fix mul_u64_u64_div_u64() precision for cputime
Date: Thu, 25 Jul 2024 17:14:58 +0200 [thread overview]
Message-ID: <20240725151458.GJ13387@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <b21d9fa7-45be-8346-db28-4c42847e2e0b@huawei.com>
On Thu, Jul 25, 2024 at 10:49:46PM +0800, zhengzucheng wrote:
> Sorry, I made a mistake here. CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set.
>
> 在 2024/7/25 22:05, Peter Zijlstra 写道:
> > On Thu, Jul 25, 2024 at 12:03:15PM +0000, Zheng Zucheng wrote:
> > > In extreme test scenarios:
> > > the 14th field utime in /proc/xx/stat is greater than sum_exec_runtime,
> > > utime = 18446744073709518790 ns, rtime = 135989749728000 ns
> > >
> > > In cputime_adjust() process, stime is greater than rtime due to
> > > mul_u64_u64_div_u64() precision problem.
> > > before call mul_u64_u64_div_u64(),
> > > stime = 175136586720000, rtime = 135989749728000, utime = 1416780000.
> > > after call mul_u64_u64_div_u64(),
> > > stime = 135989949653530
> > >
> > > unsigned reversion occurs because rtime is less than stime.
> > > utime = rtime - stime = 135989749728000 - 135989949653530
> > > = -199925530
> > > = (u64)18446744073709518790
> > >
> > > Trigger scenario:
> > > 1. User task run in kernel mode most of time.
> > > 2. The ARM64 architecture && CONFIG_VIRT_CPU_ACCOUNTING_NATIVE=y &&
> > > TICK_CPU_ACCOUNTING=y
> > >
> > > Fix mul_u64_u64_div_u64() conversion precision by reset stime to rtime
> > >
> > > Fixes: 3dc167ba5729 ("sched/cputime: Improve cputime_adjust()")
> > > Signed-off-by: Zheng Zucheng <zhengzucheng@huawei.com>
> > > ---
> > > kernel/sched/cputime.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
> > > index aa48b2ec879d..365c74e95537 100644
> > > --- a/kernel/sched/cputime.c
> > > +++ b/kernel/sched/cputime.c
> > > @@ -582,6 +582,8 @@ void cputime_adjust(struct task_cputime *curr, struct prev_cputime *prev,
> > > }
> > > stime = mul_u64_u64_div_u64(stime, rtime, stime + utime);
> > > + if (unlikely(stime > rtime))
> > > + stime = rtime;
Ooh,.. I see, this is because the generic fallback for
mul_u64_u64_div_u64() is yuck :/
On x86_64 this is just two instructions and it does a native:
u64*u64->u128
u128/u64->u64
And this should never happen. But in the generic case, we appoximate and
urgh.
So yeah, but then perhaps add a comment like:
/*
* Because mul_u64_u64_div_u64() can approximate on some
* achitectures; enforce the constraint that: a*b/(b+c) <= a.
*/
if (unlikely(stime > rtime))
stime = rtime;
Also, I would look into doing a native arm64 version, I'd be surprised
if it could not do better than the generic variant.
next prev parent reply other threads:[~2024-07-25 15:15 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-25 12:03 [PATCH -next] sched/cputime: Fix mul_u64_u64_div_u64() precision for cputime Zheng Zucheng
2024-07-25 14:05 ` Peter Zijlstra
2024-07-25 14:49 ` zhengzucheng
2024-07-25 15:14 ` Peter Zijlstra [this message]
2024-07-26 2:32 ` [PATCH v2 " Zheng Zucheng
2024-07-26 10:44 ` Oleg Nesterov
2024-07-26 13:04 ` Oleg Nesterov
2024-07-26 13:08 ` Peter Zijlstra
2024-07-26 13:30 ` Oleg Nesterov
2024-07-30 6:55 ` Uwe Kleine-König
2024-07-29 10:34 ` [tip: sched/core] " tip-bot2 for Zheng Zucheng
2024-09-02 1:56 ` [Question] Include isolated cpu to ensure that tasks are not scheduled to isolated cpu? zhengzucheng
2024-09-02 3:00 ` Waiman Long
2024-09-13 4:03 ` [Question] sched:the load is unbalanced in the VM overcommitment scenario zhengzucheng
2024-09-13 15:55 ` Vincent Guittot
2024-09-14 7:03 ` zhengzucheng
2024-09-17 6:19 ` Vincent Guittot
2024-09-13 17:17 ` Waiman Long
2024-09-14 2:15 ` zhengzucheng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240725151458.GJ13387@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=zhengzucheng@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox