From: Oleg Nesterov <oleg@redhat.com>
To: Zheng Zucheng <zhengzucheng@huawei.com>
Cc: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
bristot@redhat.com, vschneid@redhat.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 -next] sched/cputime: Fix mul_u64_u64_div_u64() precision for cputime
Date: Fri, 26 Jul 2024 12:44:29 +0200 [thread overview]
Message-ID: <20240726104429.GA21542@redhat.com> (raw)
In-Reply-To: <20240726023235.217771-1-zhengzucheng@huawei.com>
On 07/26, Zheng Zucheng wrote:
>
> before call mul_u64_u64_div_u64(),
> stime = 175136586720000, rtime = 135989749728000, utime = 1416780000.
So stime + utime == 175138003500000
> after call mul_u64_u64_div_u64(),
> stime = 135989949653530
Hmm. On x86 mul_u64_u64_div_u64(175136586720000, 135989749728000, 175138003500000)
returns 135989749728000 == rtime, see below.
Nevermind...
> --- a/kernel/sched/cputime.c
> +++ b/kernel/sched/cputime.c
> @@ -582,6 +582,12 @@ void cputime_adjust(struct task_cputime *curr, struct prev_cputime *prev,
> }
>
> stime = mul_u64_u64_div_u64(stime, rtime, stime + utime);
> + /*
> + * 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;
Thanks,
Acked-by: Oleg Nesterov <oleg@redhat.com>
-------------------------------------------------------------------------------
But perhaps it makes sense to improve the accuracy of mul_u64_u64_div_u64() ?
See the new() function in the code below.
Say, with the numbers above I get
$ ./test 175136586720000 135989749728000 175138003500000
old -> 135989749728000 e=1100089950.609375
new -> 135988649638050 e=0.609375
Oleg.
-------------------------------------------------------------------------------
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
typedef unsigned long long u64;
static inline int fls64(u64 x)
{
int bitpos = -1;
/*
* AMD64 says BSRQ won't clobber the dest reg if x==0; Intel64 says the
* dest reg is undefined if x==0, but their CPU architect says its
* value is written to set it to the same as before.
*/
asm("bsrq %1,%q0"
: "+r" (bitpos)
: "rm" (x));
return bitpos + 1;
}
static inline int ilog2(u64 n)
{
return fls64(n) - 1;
}
#define swap(a, b) \
do { typeof(a) __tmp = (a); (a) = (b); (b) = __tmp; } while (0)
static inline u64 div64_u64_rem(u64 dividend, u64 divisor, u64 *remainder)
{
*remainder = dividend % divisor;
return dividend / divisor;
}
static inline u64 div64_u64(u64 dividend, u64 divisor)
{
return dividend / divisor;
}
//-----------------------------------------------------------------------------
// current implementation of mul_u64_u64_div_u64
u64 old(u64 a, u64 b, u64 c)
{
u64 res = 0, div, rem;
int shift;
/* can a * b overflow ? */
if (ilog2(a) + ilog2(b) > 62) {
/*
* Note that the algorithm after the if block below might lose
* some precision and the result is more exact for b > a. So
* exchange a and b if a is bigger than b.
*
* For example with a = 43980465100800, b = 100000000, c = 1000000000
* the below calculation doesn't modify b at all because div == 0
* and then shift becomes 45 + 26 - 62 = 9 and so the result
* becomes 4398035251080. However with a and b swapped the exact
* result is calculated (i.e. 4398046510080).
*/
if (a > b)
swap(a, b);
/*
* (b * a) / c is equal to
*
* (b / c) * a +
* (b % c) * a / c
*
* if nothing overflows. Can the 1st multiplication
* overflow? Yes, but we do not care: this can only
* happen if the end result can't fit in u64 anyway.
*
* So the code below does
*
* res = (b / c) * a;
* b = b % c;
*/
div = div64_u64_rem(b, c, &rem);
res = div * a;
b = rem;
shift = ilog2(a) + ilog2(b) - 62;
if (shift > 0) {
/* drop precision */
b >>= shift;
c >>= shift;
if (!c)
return res;
}
}
return res + div64_u64(a * b, c);
}
u64 new(u64 a, u64 b, u64 c)
{
u64 res = 0, div, rem;
/* can a * b overflow ? */
while (ilog2(a) + ilog2(b) > 62) {
if (a > b)
swap(b, a);
if (b >= c) {
/*
* (b * a) / c is equal to
*
* (b / c) * a +
* (b % c) * a / c
*
* if nothing overflows. Can the 1st multiplication
* overflow? Yes, but we do not care: this can only
* happen if the end result can't fit in u64 anyway.
*
* So the code below does
*
* res += (b / c) * a;
* b = b % c;
*/
div = div64_u64_rem(b, c, &rem);
res += div * a;
b = rem;
continue;
}
/* drop precision */
b >>= 1;
c >>= 1;
if (!c)
return res;
}
return res + div64_u64(a * b, c);
}
int main(int argc, char **argv)
{
u64 a, b, c, ro, rn;
double rd;
assert(argc == 4);
a = strtoull(argv[1], NULL, 0);
b = strtoull(argv[2], NULL, 0);
c = strtoull(argv[3], NULL, 0);
rd = (((double)a) * b) / c;
ro = old(a, b, c);
rn = new(a, b, c);
printf("old -> %lld\te=%f\n", ro, ro - rd);
printf("new -> %lld\te=%f\n", rn, rn - rd);
return 0;
}
next prev parent reply other threads:[~2024-07-26 10:46 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
2024-07-26 2:32 ` [PATCH v2 " Zheng Zucheng
2024-07-26 10:44 ` Oleg Nesterov [this message]
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=20240726104429.GA21542@redhat.com \
--to=oleg@redhat.com \
--cc=bristot@redhat.com \
--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=peterz@infradead.org \
--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