All of lore.kernel.org
 help / color / mirror / Atom feed
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.
> 


  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 [PATCH] x86/math64: handle #DE in mul_u64_u64_div_u64() 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.