[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250614125915.65c77f87@pumpkin>
Date: Sat, 14 Jun 2025 12:59:15 +0100
From: David Laight <david.laight.linux@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-kernel@...r.kernel.org,
u.kleine-koenig@...libre.com, Nicolas Pitre <npitre@...libre.com>, Oleg
Nesterov <oleg@...hat.com>, Biju Das <biju.das.jz@...renesas.com>
Subject: Re: [PATCH v3 next 00/10] Implement mul_u64_u64_div_u64_roundup()
On Sat, 14 Jun 2025 12:27:17 +0200
Peter Zijlstra <peterz@...radead.org> wrote:
> On Sat, Jun 14, 2025 at 10:53:36AM +0100, David Laight wrote:
> > The pwm-stm32.c code wants a 'rounding up' version of mul_u64_u64_div_u64().
> > This can be done simply by adding 'divisor - 1' to the 128bit product.
> > Implement mul_u64_add_u64_div_u64(a, b, c, d) = (a * b + c)/d based on the
> > existing code.
> > Define mul_u64_u64_div_u64(a, b, d) as mul_u64_add_u64_div_u64(a, b, 0, d) and
> > mul_u64_u64_div_u64_roundup(a, b, d) as mul_u64_add_u64_div_u64(a, b, d-1, d).
>
> Another way to achieve the same would to to expose the remainder of
> mul_u64_64_div_u64(), no?
The optimised paths for small products don't give the remainder.
And you don't want to do the multiply again to generate it.
As well as the conditional increment you'd also need another test
for the quotient overflowing.
Adding 'c' to the product is cheap.
David
Powered by blists - more mailing lists