All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>,
	Denys Vlasenko <vda.linux@googlemail.com>,
	Denys Vlasenko <dvlasenk@redhat.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Oleg Nesterov <oleg@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Frederic Weisbecker <fweisbec@gmail.com>, X86 ML <x86@kernel.org>,
	Alexei Starovoitov <ast@plumgrid.com>,
	Will Drewry <wad@chromium.org>, Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH 3/4] x86: open-code register save/restore in trace_hardirqs thunks
Date: Sat, 10 Jan 2015 22:26:57 +0100	[thread overview]
Message-ID: <20150110212657.GE12218@pd.tnic> (raw)
In-Reply-To: <CA+55aFzhgnHipD_mAA6qp9bum2b_j_7_3uWN4MHtwh6y20krcg@mail.gmail.com>

On Sat, Jan 10, 2015 at 01:08:33PM -0800, Linus Torvalds wrote:
> It was true for some AMD CPU's in particular. One insn/cycle vs two.

Probably on K8: Agner Fog's insn tables show reciprocal throughput of
1/2 for MOV r64/m64 vs 1 for PUSH/POP.

> I personally would be very happy to go back to push/pop sequences.
> Even without a fancy stack engine like Intel has done for a while,
> even *simple* cores can generally pair pushes and pops. I think the

I think all the modern x86 machines have stack engines now :-)

> original Pentium already had a special magic pairing logic to pair
> pushes and pops despite both instructions using %esp. It's a common
> and fairly trivial special case, and the fact that a few AMD
> microarchitectures didn't do it is likely not really a good reason to
> avoid repeated push/pop instructions.

Well, according to the optimization manual, on F15h (Bulldozer and
later) PUSH/POP are faster than MOVs and on F16h (Jaguar and later) both
MOV and PUSH/POP have latency of 1, with MOV having a 1/2 throughput vs
PUSH/POP throughput of 1. So theoretically we can do 2 MOVs per cycle
there vs 1 PUSH/POP.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

  reply	other threads:[~2015-01-10 21:27 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-08 16:25 [PATCH 0/4] x86: entry.S cleanup Denys Vlasenko
2015-01-08 16:25 ` [PATCH 1/4] x86: entry_64.S: delete unused code Denys Vlasenko
2015-01-08 18:16   ` Borislav Petkov
2015-01-13 22:01     ` Andy Lutomirski
2015-01-08 16:25 ` [PATCH 2/4] x86: ia32entry.S: fix wrong symbolic constant usage: R11->ARGOFFSET Denys Vlasenko
2015-01-09 10:41   ` Borislav Petkov
2015-01-08 16:25 ` [PATCH 3/4] x86: open-code register save/restore in trace_hardirqs thunks Denys Vlasenko
2015-01-09 10:55   ` Borislav Petkov
2015-01-09 20:29     ` Denys Vlasenko
2015-01-10 13:52       ` Borislav Petkov
2015-01-09 12:19   ` Borislav Petkov
2015-01-09 18:54     ` Denys Vlasenko
2015-01-10 14:23       ` Borislav Petkov
2015-01-10 20:14         ` Denys Vlasenko
2015-01-10 20:17           ` Andy Lutomirski
2015-01-10 20:42             ` Borislav Petkov
2015-01-10 21:02               ` Andy Lutomirski
2015-01-10 21:09                 ` Denys Vlasenko
2015-01-10 21:27                   ` Linus Torvalds
2015-01-10 21:57                     ` Denys Vlasenko
2015-01-10 20:43             ` Denys Vlasenko
2015-01-10 21:08             ` Linus Torvalds
2015-01-10 21:26               ` Borislav Petkov [this message]
2015-01-10 22:00           ` Borislav Petkov
2015-01-10 22:03             ` Denys Vlasenko
2015-01-10 22:04             ` Andy Lutomirski
2015-01-08 16:25 ` [PATCH 4/4] x86: entry_64.S: fold SAVE_ARGS_IRQ macro into its sole user Denys Vlasenko
2015-01-10 22:00 [PATCH 0/4 v2] x86: entry.S cleanup Denys Vlasenko
2015-01-10 22:00 ` [PATCH 3/4] x86: open-code register save/restore in trace_hardirqs thunks Denys Vlasenko
2015-01-10 22:07   ` Linus Torvalds
2015-01-10 22:35     ` Denys Vlasenko
2015-01-10 22:41       ` Borislav Petkov
2015-01-11  3:33         ` Denys Vlasenko
2015-01-11 10:54           ` Borislav Petkov
2015-01-11 23:06             ` Denys Vlasenko
2015-02-11  2:38   ` 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=20150110212657.GE12218@pd.tnic \
    --to=bp@alien8.de \
    --cc=ast@plumgrid.com \
    --cc=dvlasenk@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=oleg@redhat.com \
    --cc=torvalds@linux-foundation.org \
    --cc=vda.linux@googlemail.com \
    --cc=wad@chromium.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.