public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Brian Gerst <brgerst@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Juergen Gross <jgross@suse.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Arnd Bergmann <arnd@arndb.de>
Subject: Re: [patch 01/15] x86/irq: Convey vector as argument and not in ptregs
Date: Thu, 27 Feb 2020 00:43:53 +0100	[thread overview]
Message-ID: <87eeugoqx2.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <CAMzpN2j7EHZ2bKg9SZ2Ri-qsmEoknAAJO6O5yoLn-fY8_h1B2A@mail.gmail.com>

Brian Gerst <brgerst@gmail.com> writes:
> On Wed, Feb 26, 2020 at 3:13 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>> Brian Gerst <brgerst@gmail.com> writes:
>> Now the question is whether we care about the packed stubs or just make
>> them larger by using alignment to get rid of this silly +0x80 and
>> ~vector fixup later on. The straight forward thing clearly has its charm
>> and I doubt it matters in measurable ways.
>
> I think we can get rid of the inversion.  That was done so orig_ax had
> a negative number (signifying it's not a syscall), but if you replace
> it with -1 that isn't necessary.  A simple -0x80 offset should be
> sufficient.
>
> I think it's a worthy optimization to keep.  There are 240 of these
> stubs, so increasing the allocation to 16 bytes would add 1920 bytes
> to the kernel text.

I rather pay the 2k text size for readable and straight forward
code. Can you remind me why we are actually worrying at that level about
32bit x86 instead of making it depend on CONFIG_OBSCURE?

Thanks,

        tglx

  reply	other threads:[~2020-02-26 23:44 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-25 22:47 [patch 00/15] x86/entry: Consolidation - Part V Thomas Gleixner
2020-02-25 22:47 ` [patch 01/15] x86/irq: Convey vector as argument and not in ptregs Thomas Gleixner
2020-02-26  5:13   ` Andy Lutomirski
2020-02-26  5:45   ` Brian Gerst
2020-02-26 20:13     ` Thomas Gleixner
2020-02-26 21:35       ` Andy Lutomirski
2020-02-26 23:50         ` Thomas Gleixner
2020-02-26 21:54       ` Brian Gerst
2020-02-26 23:43         ` Thomas Gleixner [this message]
2020-02-27  0:04           ` Brian Gerst
2020-02-25 22:47 ` [patch 02/15] x86/entry/64: Add ability to switch to IRQ stacks in idtentry Thomas Gleixner
2020-02-25 22:47 ` [patch 03/15] x86/entry: Add IRQENTRY_IRQ macro Thomas Gleixner
2020-02-26 15:05   ` Miroslav Benes
2020-02-25 22:47 ` [patch 04/15] x86/entry: Use idtentry for interrupts Thomas Gleixner
2020-02-25 22:47 ` [patch 05/15] x86/entry: Provide IDTEnTRY_SYSVEC Thomas Gleixner
2020-02-26  6:10   ` Andy Lutomirski
2020-02-26 20:15     ` Thomas Gleixner
2020-02-25 22:47 ` [patch 06/15] x86/entry: Convert APIC interrupts to IDTENTRY_SYSVEC Thomas Gleixner
2020-02-25 22:47 ` [patch 07/15] x86/entry: Convert SMP system vectors " Thomas Gleixner
2020-02-25 22:47 ` [patch 08/15] x86/entry: Convert various system vectors Thomas Gleixner
2020-02-25 22:47 ` [patch 09/15] x86/entry: Convert KVM vectors to IDTENTRY_SYSVEC Thomas Gleixner
2020-02-26 10:54   ` Paolo Bonzini
2020-02-25 22:47 ` [patch 10/15] x86/entry: Convert various hypervisor " Thomas Gleixner
2020-02-25 22:47 ` [patch 11/15] x86/entry: Convert XEN hypercall vector " Thomas Gleixner
2020-02-25 22:47 ` [patch 12/15] x86/entry: Remove the apic/BUILD interrupt leftovers Thomas Gleixner
2020-02-25 22:47 ` [patch 13/15] x86/entry/32: Remove redundant irq disable code Thomas Gleixner
2020-02-25 22:47 ` [patch 14/15] x86/entry: Provide return_from exception() Thomas Gleixner
2020-02-25 22:47 ` [patch 15/15] x86/entry: Use return_from_exception() Thomas Gleixner
2020-02-26  9:53 ` [patch 00/15] x86/entry: Consolidation - Part V Peter Zijlstra
2020-02-26 10:02   ` Peter Zijlstra

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=87eeugoqx2.fsf@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=arnd@arndb.de \
    --cc=brgerst@gmail.com \
    --cc=jgross@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rostedt@goodmis.org \
    --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