All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Denys Vlasenko <dvlasenk@redhat.com>
Cc: "Andy Lutomirski" <luto@amacapital.net>,
	"Sara Sharon" <sara.sharon@intel.com>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Vinod Koul" <vinod.koul@intel.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Johannes Berg" <johannes.berg@intel.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	"Andy Lutomirski" <luto@kernel.org>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	"Ingo Molnar" <mingo@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"Adrian Hunter" <adrian.hunter@intel.com>
Subject: Re: RFC: Petition Intel/AMD to add POPF_IF insn
Date: Wed, 17 Aug 2016 14:26:51 -0700	[thread overview]
Message-ID: <CA+55aFw=nt9+Jk2O2cuYaTJ7qLoO3Gjv=tUH6bwjFFTg=sNHfQ@mail.gmail.com> (raw)
In-Reply-To: <CA+55aFwfEzVCdeVdK6hUO4s_yy-wisPmQhtYbNUr4hFuRm8NkQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1414 bytes --]

On Wed, Aug 17, 2016 at 12:37 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Replace the "popf" with "if (val & X86_EFLAGS_IF) local_irq_enable();"
> and see how that works out. Play with inlining it or not, and see if
> the branch predictor matters.

.. actually, thinking a bit more about it, I really don't think the
branch predictor will even matter.

We sure as hell shouldn't have nested irq-safe interrupts in paths
that matter from a performance angle, so the normal case for
spin_unlock_irqrestore() should be to enable interrupts again.

And if interrupts are disabled because the caller is actually in
interrupt context, I don't think the branch prediction is going to
matter, compared to the irq overhead.

So test this trivial patch. It's ENTIRELY UNTESTED. It may be complete
crap and not even compile. But I did test it on
kernel/locking/spinlock.c, and the generated code is beautiful:

  _raw_spin_unlock_irqrestore:
        testl   $512, %esi      #, flags
        movb    $0, (%rdi)      #, MEM[(volatile __u8 *)lock_2(D)]
        je      .L2
        sti
  .L2:
        ret

so maybe the silly popf has always just been stupid.

Of course, if somebody uses native_restore_fl() to actually *disable*
interrupts (when they weren't already disabled), then this untested
patch will just not work. But why would you do somethign so stupid?
Famous last words...

                 Linus

[-- Attachment #2: patch.diff --]
[-- Type: text/plain, Size: 1127 bytes --]

 arch/x86/include/asm/irqflags.h | 26 ++++++++++++--------------
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
index b77f5edb03b0..76c4ebfab0be 100644
--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -8,6 +8,16 @@
  * Interrupt control:
  */
 
+static inline void native_irq_disable(void)
+{
+	asm volatile("cli": : :"memory");
+}
+
+static inline void native_irq_enable(void)
+{
+	asm volatile("sti": : :"memory");
+}
+
 static inline unsigned long native_save_fl(void)
 {
 	unsigned long flags;
@@ -28,20 +38,8 @@ static inline unsigned long native_save_fl(void)
 
 static inline void native_restore_fl(unsigned long flags)
 {
-	asm volatile("push %0 ; popf"
-		     : /* no output */
-		     :"g" (flags)
-		     :"memory", "cc");
-}
-
-static inline void native_irq_disable(void)
-{
-	asm volatile("cli": : :"memory");
-}
-
-static inline void native_irq_enable(void)
-{
-	asm volatile("sti": : :"memory");
+	if (flags & X86_EFLAGS_IF)
+		native_irq_enable();
 }
 
 static inline void native_safe_halt(void)

  reply	other threads:[~2016-08-17 21:26 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-17 17:20 RFC: Petition Intel/AMD to add POPF_IF insn Denys Vlasenko
2016-08-17 17:30 ` Christian König
2016-08-17 18:34   ` Denys Vlasenko
2016-08-17 17:32 ` Linus Torvalds
2016-08-17 18:41   ` Denys Vlasenko
     [not found]     ` <CA+55aFwmxwQBkyDjombS4cy1q=a_buhmDjDnaa8rdC8ZDaDYEA@mail.gmail.com>
2016-08-17 19:13       ` Andy Lutomirski
2016-08-17 19:26         ` Denys Vlasenko
2016-08-17 19:32           ` Linus Torvalds
2016-08-17 19:35             ` Denys Vlasenko
2016-08-17 19:54               ` Linus Torvalds
2016-08-17 19:37             ` Linus Torvalds
2016-08-17 21:26               ` Linus Torvalds [this message]
2016-08-17 21:35                 ` Linus Torvalds
2016-08-17 21:43                   ` Andy Lutomirski
2016-08-17 21:48                     ` Linus Torvalds
2016-08-18 13:26                       ` Denys Vlasenko
2016-08-18 17:24                         ` Linus Torvalds
2016-08-18 17:47                           ` Denys Vlasenko
2016-08-18 17:49                             ` Denys Vlasenko
2016-08-19 10:54                           ` Paolo Bonzini
2016-08-31 11:12                             ` Denys Vlasenko
2016-08-18  9:21                   ` Denys Vlasenko
2016-08-18 12:18                     ` Denys Vlasenko
2016-08-18 17:22                       ` Paolo Bonzini
2016-08-17 19:29         ` Linus Torvalds

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='CA+55aFw=nt9+Jk2O2cuYaTJ7qLoO3Gjv=tUH6bwjFFTg=sNHfQ@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.deucher@amd.com \
    --cc=christian.koenig@amd.com \
    --cc=dan.j.williams@intel.com \
    --cc=dvlasenk@redhat.com \
    --cc=johannes.berg@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=sara.sharon@intel.com \
    --cc=vinod.koul@intel.com \
    --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.