All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>, Brian Gerst <brgerst@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	X86 ML <x86@kernel.org>, Peter Zijlstra <peterz@infradead.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v3 5/5] x86/entry/64: Bypass enter_from_user_mode on non-context-tracking boots
Date: Mon, 16 Nov 2015 23:50:49 +0100	[thread overview]
Message-ID: <20151116225048.GA5212@lerouge> (raw)
In-Reply-To: <CALCETrUd89QuMUsVj7USHZX1=RK_KdavCBsUV8+rtJ4+WygQ3A@mail.gmail.com>

On Mon, Nov 16, 2015 at 11:10:55AM -0800, Andy Lutomirski wrote:
> On Nov 13, 2015 7:26 AM, "Frederic Weisbecker" <fweisbec@gmail.com> wrote:
> >
> > On Thu, Nov 12, 2015 at 12:59:04PM -0800, Andy Lutomirski wrote:
> > > On CONFIG_CONTEXT_TRACKING kernels that have context tracking
> > > disabled at runtime (which includes most distro kernels), we still
> > > have the overhead of a call to enter_from_user_mode in interrupt and
> > > exception entries.
> > >
> > > If jump labels are available, this uses the jump label
> > > infrastructure to skip the call.
> >
> > Looks good. But why are we still calling context tracking code on IRQs at all?
> 
> Same reasons as before:
> 
> 1. This way the IRQ exit path is almost completely shared with all the
> other exit paths.

I'm all for consolidation in general. Unless it brings bad middle states.

If I knew before that I would have to argue endlessly in order to protest against
these context tracking changes, I would have NACK'ed the x86 consolidation rework in
the state it was while it got merged.

> 
> 2. It combines the checks for which context we were in with what CPL
> we entered from.
> 
> Part 2 should be complete across the whole x86 kernel soon once the
> 64-bit syscall code gets fixed up.
> 
> We should get rid of the duplication in the irq entry hooks.  Want to
> help with that?

Which one? The duplication against irq_enter() and irq_exit()?

I think that irq_exit() should be moved to the IRQ very end and perform the
final signal/schedule/preempt_schedule_irq() loop. But it requires a bit of
rework on all archs in order to do that. This could be done iteratively though.

> Presumably we should do the massive remote polling speedup to the nohz code,

Hmm, I don't get what you mean here.

> and we should also teach enter_from_user_mode to transition directly to IRQ state as
> appropriate.  Then irq_enter can be much faster.

I don't get what you mean here either. You mean calling irq_enter() from enter_from_user_mode()?


  reply	other threads:[~2015-11-16 22:50 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-12 20:58 [PATCH v3 0/5] x86 entry stuff, maybe for 4.4 Andy Lutomirski
2015-11-12 20:59 ` [PATCH v3 1/5] x86/entry/64: Fix irqflag tracing wrt context tracking Andy Lutomirski
2015-11-24  9:35   ` [tip:x86/asm] " tip-bot for Andy Lutomirski
2015-11-12 20:59 ` [PATCH v3 2/5] context_tracking: Switch to new static_branch API Andy Lutomirski
2015-11-24  9:35   ` [tip:x86/asm] " tip-bot for Andy Lutomirski
2015-11-12 20:59 ` [PATCH v3 3/5] x86/asm: Error out if asm/jump_label.h is included inappropriately Andy Lutomirski
2015-11-13 14:13   ` Thomas Gleixner
2015-11-24  9:35   ` [tip:x86/asm] x86/asm: Error out if asm/ jump_label.h " tip-bot for Andy Lutomirski
2015-11-12 20:59 ` [PATCH v3 4/5] x86/asm: Add asm macros for static keys/jump labels Andy Lutomirski
2015-11-13 14:22   ` Thomas Gleixner
2015-11-24  9:36   ` [tip:x86/asm] " tip-bot for Andy Lutomirski
2015-11-12 20:59 ` [PATCH v3 5/5] x86/entry/64: Bypass enter_from_user_mode on non-context-tracking boots Andy Lutomirski
2015-11-13 14:23   ` Thomas Gleixner
2015-11-13 15:26   ` Frederic Weisbecker
2015-11-16 19:10     ` Andy Lutomirski
2015-11-16 22:50       ` Frederic Weisbecker [this message]
2015-11-16 23:57         ` Andy Lutomirski
2015-11-19  0:57           ` Frederic Weisbecker
2015-11-24  9:36   ` [tip:x86/asm] " tip-bot for Andy Lutomirski

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=20151116225048.GA5212@lerouge \
    --to=fweisbec@gmail.com \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.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 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.