linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lai Jiangshan <jiangshanlai@gmail.com>
To: Borislav Petkov <bp@alien8.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>, X86 ML <x86@kernel.org>,
	Lai Jiangshan <jiangshan.ljs@antgroup.com>,
	Ingo Molnar <mingo@redhat.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH V5 3/7] x86/entry: Move PUSH_AND_CLEAR_REGS out of error_entry()
Date: Wed, 13 Apr 2022 11:48:21 +0800	[thread overview]
Message-ID: <CAJhGHyC7KUj=s+w+isBewdL7iyUyEm4h++rWRoz2zBc0zAD2gw@mail.gmail.com> (raw)
In-Reply-To: <YlWNIj198mKM3hMG@zn.tnic>

On Tue, Apr 12, 2022 at 10:31 PM Borislav Petkov <bp@alien8.de> wrote:
>
> On Tue, Apr 12, 2022 at 09:52:44PM +0800, Lai Jiangshan wrote:
> > The mapped size for the text is always 2M when the kernel is booted
> > since it is 2M-aligned.  So I don't think the size is a concern.
>
> This is not how this argumentation works: you add 0.01% size increase
> here, 0.01% slowdown there and it all soon adds up into a bloated
> kernel. Besides, nowadays the kernel runs a lot as a guest and guest
> kernel size does matter.

I agree with you.

I meant the real .entry.text size is unchanged.  No matter what
the complied .entry.text size is, 5.5k before the patch, or 8.2k
after the patch, the size of .entry.text in the kernel is always 2M.

But the overall size is enlarged which is a concern.

>
> So no, just because you want to turn error_entry() into C code and for
> that you'll add some bloat doesn't justify it in my book. All changes to
> core code need to be absolutely needed and justifiable.
>
> > For example, a heavy page fault and IPI or timer at the same time.
> > I'm not sure if it is a real case.
>
> I wouldn't be surprised if it shows in some perf profiles.
>
> > I'm Okay with asm_error_entry().  And also we can use an ASM function
> > containing PUSH_AND_CLEAR_REGS only.
>
> Just do the necessary and minimal thing - this is core code and in asm
> for that matter, so be conservative pls. This is not some random driver.
>

I will follow your instructions and add an extra ASM function.

And maybe add this to the changelog:

A function call is added for every interrupt or exception, but it
is a low-level asm function call and actually, only a "call" and a
"ret" instructions are added.  It will enable error_entry() to be
C code that can use inlined sync_regs() and save a C function call
which will reduce more instructions in return.

I'm also waiting for reviews for other patches and I'm not going to
send this new code too soon since I don't want to send a new revision
with only this patch updated.

Thanks
Lai

  reply	other threads:[~2022-04-13  3:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-12 12:15 [PATCH V5 0/7] x86/entry: Clean up entry code Lai Jiangshan
2022-04-12 12:15 ` [PATCH V5 1/7] x86/traps: Move pt_regs only in fixup_bad_iret() Lai Jiangshan
2022-04-12 12:15 ` [PATCH V5 2/7] x86/entry: Switch the stack after error_entry() returns Lai Jiangshan
2022-04-12 12:15 ` [PATCH V5 3/7] x86/entry: Move PUSH_AND_CLEAR_REGS out of error_entry() Lai Jiangshan
2022-04-12 13:26   ` Borislav Petkov
2022-04-12 13:52     ` Lai Jiangshan
2022-04-12 14:30       ` Borislav Petkov
2022-04-13  3:48         ` Lai Jiangshan [this message]
2022-04-13  8:39           ` Borislav Petkov
2022-04-12 12:15 ` [PATCH V5 4/7] x86/entry: Move cld to the start of idtentry macro Lai Jiangshan
2022-04-12 12:15 ` [PATCH V5 5/7] x86/entry: Don't call error_entry() for XENPV Lai Jiangshan
2022-04-20 16:32   ` Borislav Petkov
2022-04-12 12:15 ` [PATCH V5 6/7] x86/entry: Convert SWAPGS to swapgs and remove the definition of SWAPGS Lai Jiangshan
2022-04-12 12:15 ` [PATCH V5 7/7] x86/entry: Use idtentry macro for entry_INT80_compat Lai Jiangshan
2022-04-25 10:24   ` Thomas Gleixner
2022-04-25 13:25     ` Lai Jiangshan

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='CAJhGHyC7KUj=s+w+isBewdL7iyUyEm4h++rWRoz2zBc0zAD2gw@mail.gmail.com' \
    --to=jiangshanlai@gmail.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jiangshan.ljs@antgroup.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.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;
as well as URLs for NNTP newsgroup(s).