From: Ingo Molnar <mingo@kernel.org>
To: Brian Gerst <brgerst@gmail.com>
Cc: "Andy Lutomirski" <luto@amacapital.net>,
"Andy Lutomirski" <luto@kernel.org>,
"the arch/x86 maintainers" <x86@kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Borislav Petkov" <bp@alien8.de>,
"Frédéric Weisbecker" <fweisbec@gmail.com>,
"Denys Vlasenko" <dvlasenk@redhat.com>,
"Linus Torvalds" <torvalds@linux-foundation.org>
Subject: Re: [PATCH 07/12] x86/entry/64: Always run ptregs-using syscalls on the slow path
Date: Tue, 8 Dec 2015 19:56:08 +0100 [thread overview]
Message-ID: <20151208185608.GA3004@gmail.com> (raw)
In-Reply-To: <CAMzpN2jRGcfYOqcjxPvd+ufXK=HHU+dfUftQGnLVmohBPd6o6Q@mail.gmail.com>
* Brian Gerst <brgerst@gmail.com> wrote:
> > We could adjust it a bit and check whether we're in C land (by checking rsp
> > for ts) and jump into the slow path if we aren't, but I'm not sure this is a
> > huge win. It does save some rodata space by avoiding duplicating the table.
>
> The syscall table is huge. 545*8 bytes, over a full page. Duplicating it for
> just a few different entries is wasteful.
Note that what matters more is cache footprint, not pure size: 1K of RAM overhead
for something as fundamental as system calls is trivial cost.
So the questions to ask are along these lines:
- what is the typical locality of access (do syscall numbers cluster in time and
space)
- how frequently would the two tables be accessed (is one accessed less
frequently than the other?)
- subsequently how does the effective cache footprint change with the
duplication?
it might still end up not being worth it - but it's not the RAM cost that is the
main factor IMHO.
Thanks,
Ingo
next prev parent reply other threads:[~2015-12-08 18:56 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-07 21:51 [PATCH 00/12] x86: Rewrite 64-bit syscall code Andy Lutomirski
2015-12-07 21:51 ` [PATCH 01/12] selftests/x86: Extend Makefile to allow 64-bit only tests Andy Lutomirski
2015-12-08 9:34 ` Borislav Petkov
2015-12-09 18:55 ` Andy Lutomirski
2015-12-09 19:11 ` Shuah Khan
2015-12-09 19:22 ` Andy Lutomirski
2015-12-09 19:58 ` Shuah Khan
2015-12-07 21:51 ` [PATCH 02/12] selftests/x86: Add check_initial_reg_state Andy Lutomirski
2015-12-08 9:54 ` Borislav Petkov
2015-12-09 18:56 ` Andy Lutomirski
2015-12-09 19:09 ` Borislav Petkov
2015-12-09 19:20 ` Andy Lutomirski
2015-12-09 19:28 ` Borislav Petkov
2015-12-07 21:51 ` [PATCH 03/12] x86/syscalls: Refactor syscalltbl.sh Andy Lutomirski
2015-12-07 21:51 ` [PATCH 04/12] x86/syscalls: Remove __SYSCALL_COMMON and __SYSCALL_X32 Andy Lutomirski
2015-12-07 21:51 ` [PATCH 05/12] x86/syscalls: Move compat syscall entry handling into syscalltbl.sh Andy Lutomirski
2015-12-07 21:51 ` [PATCH 06/12] x86/syscalls: Add syscall entry qualifiers Andy Lutomirski
2015-12-07 21:51 ` [PATCH 07/12] x86/entry/64: Always run ptregs-using syscalls on the slow path Andy Lutomirski
2015-12-08 0:50 ` Brian Gerst
2015-12-08 0:54 ` Brian Gerst
2015-12-08 1:12 ` Andy Lutomirski
2015-12-08 13:07 ` Brian Gerst
2015-12-08 18:56 ` Ingo Molnar [this message]
2015-12-08 21:51 ` Andy Lutomirski
2015-12-09 4:43 ` Brian Gerst
2015-12-09 5:45 ` Andy Lutomirski
2015-12-09 6:21 ` Andy Lutomirski
2015-12-09 12:52 ` Brian Gerst
2015-12-09 13:02 ` [PATCH] x86/entry/64: Remove duplicate syscall table for fast path Brian Gerst
2015-12-09 18:53 ` Andy Lutomirski
2015-12-09 21:08 ` Brian Gerst
2015-12-09 21:15 ` Andy Lutomirski
2015-12-09 23:50 ` Andy Lutomirski
2015-12-10 5:42 ` Brian Gerst
2015-12-10 5:54 ` Andy Lutomirski
2015-12-09 19:30 ` Andy Lutomirski
2015-12-07 21:51 ` [PATCH 08/12] x86/entry/64: Call all native slow-path syscalls with full pt-regs Andy Lutomirski
2015-12-07 21:51 ` [PATCH 09/12] x86/entry/64: Stop using int_ret_from_sys_call in ret_from_fork Andy Lutomirski
2015-12-07 21:51 ` [PATCH 10/12] x86/entry/64: Migrate the 64-bit syscall slow path to C Andy Lutomirski
2015-12-07 21:51 ` [PATCH 11/12] x86/entry/32: Change INT80 to be an interrupt gate Andy Lutomirski
2016-04-01 1:45 ` Rusty Russell
2016-04-01 7:40 ` [tip:x86/urgent] lguest, x86/entry/32: Fix handling of guest syscalls using interrupt gates tip-bot for Rusty Russell
2015-12-07 21:51 ` [PATCH 12/12] x86/entry: Do enter_from_user_mode with IRQs off Andy Lutomirski
2015-12-07 22:55 ` [PATCH 00/12] x86: Rewrite 64-bit syscall code Andy Lutomirski
2015-12-08 4:42 ` Ingo Molnar
2015-12-08 5:42 ` Andy Lutomirski
2015-12-08 7:00 ` 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=20151208185608.GA3004@gmail.com \
--to=mingo@kernel.org \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=dvlasenk@redhat.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.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.