Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1286868
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 07/12] x86/entry/64: Always run ptregs-using syscalls on the slow path |
| Date | 2015-12-08 23:00 +0100 |
| Message-ID | <qDysG-7MA-1@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <qDeNj-3D4-3@gated-at.bofh.it> <qDeNj-3D4-1@gated-at.bofh.it> <qDf6G-40S-5@gated-at.bofh.it> <qDqbM-2Nk-25@gated-at.bofh.it> <qDvEu-60F-25@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Tue, Dec 8, 2015 at 10:56 AM, Ingo Molnar <mingo@kernel.org> wrote: > > * 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) > I suspect that they do. Web servers will call send over and over, for example. > - how frequently would the two tables be accessed (is one accessed less > frequently than the other?) On setups that don't bail right away, the fast path table gets hit most of the time. On setups that do bail right away (context tracking on, for example), we exclusively use the slow path table. > > - subsequently how does the effective cache footprint change with the > duplication? In the worst case (repeatedly forking, for example, but I doubt we care about that case), the duplication adds one extra cacheline. > > it might still end up not being worth it - but it's not the RAM cost that is the > main factor IMHO. Agreed. One option: borrow the high bit to indicate "needs ptregs". This adds a branch to both the fast path and the slow path, but it avoids the cache hit. Brian's approach gets the best of all worlds except that, if I understand it right, it's a bit fragile. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH 07/12] x86/entry/64: Always run ptregs-using syscalls on the slow path Andy Lutomirski <luto@kernel.org> - 2015-12-07 23:00 +0100
Re: [PATCH 07/12] x86/entry/64: Always run ptregs-using syscalls on the slow path Brian Gerst <brgerst@gmail.com> - 2015-12-08 02:00 +0100
Re: [PATCH 07/12] x86/entry/64: Always run ptregs-using syscalls on the slow path Andy Lutomirski <luto@amacapital.net> - 2015-12-08 02:20 +0100
Re: [PATCH 07/12] x86/entry/64: Always run ptregs-using syscalls on the slow path Brian Gerst <brgerst@gmail.com> - 2015-12-08 14:10 +0100
Re: [PATCH 07/12] x86/entry/64: Always run ptregs-using syscalls on the slow path Ingo Molnar <mingo@kernel.org> - 2015-12-08 20:00 +0100
Re: [PATCH 07/12] x86/entry/64: Always run ptregs-using syscalls on the slow path Andy Lutomirski <luto@amacapital.net> - 2015-12-08 23:00 +0100
Re: [PATCH 07/12] x86/entry/64: Always run ptregs-using syscalls on the slow path Brian Gerst <brgerst@gmail.com> - 2015-12-08 02:00 +0100
Re: [PATCH 07/12] x86/entry/64: Always run ptregs-using syscalls on the slow path Brian Gerst <brgerst@gmail.com> - 2015-12-09 05:50 +0100
Re: [PATCH 07/12] x86/entry/64: Always run ptregs-using syscalls on the slow path Andy Lutomirski <luto@amacapital.net> - 2015-12-09 06:50 +0100
Re: [PATCH 07/12] x86/entry/64: Always run ptregs-using syscalls on the slow path Andy Lutomirski <luto@amacapital.net> - 2015-12-09 07:30 +0100
Re: [PATCH 07/12] x86/entry/64: Always run ptregs-using syscalls on the slow path Brian Gerst <brgerst@gmail.com> - 2015-12-09 14:00 +0100
[PATCH] x86/entry/64: Remove duplicate syscall table for fast path Brian Gerst <brgerst@gmail.com> - 2015-12-09 14:10 +0100
Re: [PATCH] x86/entry/64: Remove duplicate syscall table for fast path Andy Lutomirski <luto@amacapital.net> - 2015-12-09 20:00 +0100
Re: [PATCH] x86/entry/64: Remove duplicate syscall table for fast path Brian Gerst <brgerst@gmail.com> - 2015-12-09 22:10 +0100
Re: [PATCH] x86/entry/64: Remove duplicate syscall table for fast path Andy Lutomirski <luto@amacapital.net> - 2015-12-09 22:20 +0100
Re: [PATCH] x86/entry/64: Remove duplicate syscall table for fast path Andy Lutomirski <luto@amacapital.net> - 2015-12-10 01:00 +0100
Re: [PATCH] x86/entry/64: Remove duplicate syscall table for fast path Brian Gerst <brgerst@gmail.com> - 2015-12-10 06:50 +0100
Re: [PATCH] x86/entry/64: Remove duplicate syscall table for fast path Andy Lutomirski <luto@amacapital.net> - 2015-12-10 07:00 +0100
[PATCH] x86/entry/64: Remove duplicate syscall table for fast path Andy Lutomirski <luto@kernel.org> - 2015-12-09 20:40 +0100
csiph-web