From: David Laight <david.laight.linux@gmail.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"Li,Rongqing" <lirongqing@baidu.com>,
Steven Rostedt <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org, x86@kernel.org
Subject: Re: [PATCH] x86/math64: handle #DE in mul_u64_u64_div_u64()
Date: Fri, 25 Jul 2025 22:46:22 +0100 [thread overview]
Message-ID: <20250725224622.2d718f12@pumpkin> (raw)
In-Reply-To: <20250725101201.GA8700@redhat.com>
On Fri, 25 Jul 2025 12:12:02 +0200
Oleg Nesterov <oleg@redhat.com> wrote:
> On 07/24, H. Peter Anvin wrote:
> >
> > On July 24, 2025 4:14:26 AM PDT, Oleg Nesterov <oleg@redhat.com> wrote:
> > >Finally. If we really want to optimize this function as much as possible,
> > >we can add the CONFIG_CC_HAS_ASM_GOTO_OUTPUT version as Peter suggests.
> > >I guess this should work:
>
> ...
>
> > >> Forgot to mention... Not that I think this is a good idea, but if we don't
> > >> use BUG/WARN, we can probably add EX_FLAG_ and do something like below.
>
> ...
>
> > Seems good to me.
>
> Thanks, but which one? "asm goto" or EX_FLAG_XXX_AX hack?
>
> As for the latter. I took another look at asm/extable_fixup_types.h
> and it turns out we don't need a new EX_FLAG_, this version
>
> static inline u64 mul_u64_u64_div_u64(u64 a, u64 mul, u64 div)
> {
> u64 q;
>
> asm ("mulq %2; 1: divq %3; 2:\n"
> _ASM_EXTABLE_TYPE(1b, 2b, EX_TYPE_IMM_REG | EX_DATA_IMM(-1))
That should be _ASM_EXTABLE_TYPE_REG() with an extra %%rax parameter.
It works because ax is register zero.
> : "=a" (q)
> : "a" (a), "rm" (mul), "rm" (div)
The "rm" should both be ASM_INPUT_RM
> : "rdx");
>
> return q;
> }
>
> seems to work and I guess it is the absolute winner performance wise.
>
> But to me the main question is: Peter, David, do we want to add
> BUG and/or WARN into mul_u64_u64_div_u64??? If yes, then this version
> won't work.
Looking through the code in extable.[ch] there is actually scope for adding
an extra EX_TYPE that is the same as IMM_REG but contains a WARN_ONCE().
It would be a 'global' ONCE for all such traps, but that probably doesn't matter.
The easiest way to make it 'per trap site' is to modify the 'exception_table_entry'
itself (eg change the type), but that might not be acceptable.
An alternative would be a special EX_TYPE_DIVIDE_OVERFLOW with an explicit message.
Probably best to leave all that for later.
Perhaps more useful would be adding an 'int *overflow' argument.
If not a compile-time NULL then set to 0 on entry and -1 if there is a trap.
That would need the 'jmp in the normal path' asm version - so two copies
of the entire asm block.
Another one for a later patch.
David
>
> Oleg.
>
next prev parent reply other threads:[~2025-07-25 21:46 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-21 13:04 Oleg Nesterov
2025-07-21 18:20 ` David Laight
2025-07-22 10:50 ` Oleg Nesterov
2025-07-22 12:09 ` David Laight
2025-07-22 13:21 ` Oleg Nesterov
2025-07-22 22:03 ` David Laight
2025-07-23 9:38 ` Oleg Nesterov
2025-07-23 21:48 ` David Laight
2025-07-24 8:11 ` Oleg Nesterov
2025-07-24 8:25 ` Oleg Nesterov
2025-07-24 11:14 ` Oleg Nesterov
2025-07-25 1:00 ` H. Peter Anvin
2025-07-25 10:12 ` Oleg Nesterov
2025-07-25 21:46 ` David Laight [this message]
2025-07-26 9:55 ` Oleg Nesterov
2025-07-24 12:00 ` David Laight
2025-07-24 13:58 ` Oleg Nesterov
2025-07-22 16:53 ` H. Peter Anvin
2025-07-22 21:53 ` David Laight
2025-07-22 16:50 ` H. Peter Anvin
2025-07-22 17:58 ` Oleg Nesterov
2025-07-22 18:12 ` H. Peter Anvin
2025-07-22 18:38 ` Oleg Nesterov
2025-07-22 19:26 ` H. Peter Anvin
2025-07-22 21:56 ` David Laight
2025-07-27 12:34 ` [PATCH v2] " Oleg Nesterov
2025-07-28 18:53 ` David Laight
2025-07-30 2:30 ` [????] " Li,Rongqing
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=20250725224622.2d718f12@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lirongqing@baidu.com \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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
Powered by JetHome