From: Ingo Molnar <mingo@kernel.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Steven Rostedt <rostedt@goodmis.org>,
Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>,
Oleg Nesterov <oleg@redhat.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
Alexei Starovoitov <ast@plumgrid.com>,
Will Drewry <wad@chromium.org>, Kees Cook <keescook@chromium.org>,
X86 ML <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/4] x86: save user rsp in pt_regs->sp on SYSCALL64 fastpath
Date: Tue, 10 Mar 2015 14:26:06 +0100 [thread overview]
Message-ID: <20150310132606.GC26185@gmail.com> (raw)
In-Reply-To: <CALCETrWMiyJxaUKVFG-sm_HeQeq0Z7JitSEK64ZZXxgN8NSmig@mail.gmail.com>
* Andy Lutomirski <luto@amacapital.net> wrote:
> > Since this patch does add two extra MOVs,
> > I did benchmark these patches. They add exactly one cycle
> > to system call code path on my Sandy Bridge CPU.
>
> Personally, I'm willing to pay that cycle. It could be a bigger
> savings on context switch, and the simplification it enables is
> pretty good.
But, but ... context switches are a relative slow path, compared to
system calls. And I say this with the scheduler maintainer hat on as
well.
So this is not a good bargain IMHO, assuming it's not some _huge_
difference in maintainability - but having an extra percpu field
isn't really much of a problem.
I don't claim that we couldn't in some other situation decide that a
certain type of speedup isn't worth it - but what's the big problem
here? A bit of arithmetics shouldn't be a problem?
Thanks,
Ingo
next prev parent reply other threads:[~2015-03-10 13:26 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-09 18:39 [PATCH 0/4 v2] x86: entry_64.S: steps towards simpler iret frame handling Denys Vlasenko
2015-03-09 18:39 ` [PATCH 1/4] x86: save r11 into pt_regs->flags on SYSCALL64 fastpath Denys Vlasenko
2015-03-09 20:02 ` Andy Lutomirski
2015-03-16 12:04 ` [tip:x86/asm] x86/asm/entry/64: Save R11 into pt_regs-> flags " tip-bot for Denys Vlasenko
2015-03-09 18:39 ` [PATCH 3/4] x86: save user rsp in pt_regs->sp " Denys Vlasenko
2015-03-09 20:11 ` Andy Lutomirski
2015-03-09 20:32 ` Denys Vlasenko
2015-03-09 20:43 ` Andy Lutomirski
2015-03-10 12:51 ` Ingo Molnar
2015-03-10 13:10 ` Andy Lutomirski
2015-03-10 13:18 ` Denys Vlasenko
2015-03-10 13:20 ` Andy Lutomirski
2015-03-10 13:26 ` Ingo Molnar [this message]
2015-03-10 13:21 ` Ingo Molnar
2015-03-10 13:26 ` Andy Lutomirski
2015-03-10 14:00 ` Denys Vlasenko
2015-03-10 14:02 ` Andy Lutomirski
2015-03-10 14:09 ` Denys Vlasenko
2015-03-10 13:28 ` Ingo Molnar
2015-03-10 13:50 ` Denys Vlasenko
2015-03-16 9:44 ` Ingo Molnar
2015-03-16 12:05 ` [tip:x86/asm] x86/asm/entry/64: Save user RSP in pt_regs-> sp " tip-bot for Denys Vlasenko
2015-03-10 6:00 ` [PATCH 0/4 v2] x86: entry_64.S: steps towards simpler iret frame handling Ingo Molnar
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=20150310132606.GC26185@gmail.com \
--to=mingo@kernel.org \
--cc=ast@plumgrid.com \
--cc=bp@alien8.de \
--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=rostedt@goodmis.org \
--cc=torvalds@linux-foundation.org \
--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.