Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1286868

Re: [PATCH 07/12] x86/entry/64: Always run ptregs-using syscalls on the slow path

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

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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