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

Groups > linux.kernel > #1176705 > unrolled thread

Re: [PATCH v4 14/17] x86/asm/entry/64: Migrate error and interrupt exit work to C

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v4 14/17] x86/asm/entry/64: Migrate error and interrupt  exit work to C Andy Lutomirski <luto@amacapital.net> - 2015-07-03 18:30 +0200
    Re: [PATCH v4 14/17] x86/asm/entry/64: Migrate error and interrupt  exit work to C Andy Lutomirski <luto@amacapital.net> - 2015-07-03 18:30 +0200

#1176705 — Re: [PATCH v4 14/17] x86/asm/entry/64: Migrate error and interrupt exit work to C

On Thu, Jul 2, 2015 at 11:33 PM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Andy Lutomirski <luto@amacapital.net> wrote:
>
>> If we move even more of this stuff into C, then this problem goes away.  "call
>> enter_from_user_mode" turns into "enter_from_user_mode()" or similar.
>
> Yes. I think we should first see how that process works out, and then see what
> else can be done. For the initial step I'm willing to trade up to 10 cycles in
> exchange for sane and maintainable x86 entry code that we can then speed up ...
>
> I presume we are still within that budget?
>

I haven't benchmarked very carefully.  IIRC syscall timing was
unaffected by this series.  Exceptions ought to be unaffected unless
something very weird is going on with the trace cache or branch
predictor.  IRQs will slow down by a couple cycles (I'm guessing 5,
since it's more or less the same change I benchmarked when I was
playing with the next pile of patches).

My current plan is to try to send the 32-bit asm changes some time
next week (after I find a vm86-using DOS game to test) and then the
actual performance-affecting patch after that.

--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/

[toc] | [next] | [standalone]

#1176707

On Fri, Jul 3, 2015 at 9:27 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>
> I haven't benchmarked very carefully.  IIRC syscall timing was
> unaffected by this series.  Exceptions ought to be unaffected unless
> something very weird is going on with the trace cache or branch
> predictor.  IRQs will slow down by a couple cycles (I'm guessing 5,
> since it's more or less the same change I benchmarked when I was
> playing with the next pile of patches).

One clarification: I bet that context tracking performance changes
with these patches, but it sucked before and it'll suck afterwards
regardless.  I think that these patches are a good step in making it
not suck, though -- they will allow us to only change ct state once on
entry and once on exit, and we used to get it wrong.  They also allow
us to do context tracking with IRQs off, which Rik van Riel wanted to
help his speedup project.

So, in the long run, I expect a huge context tracking improvement, and
these patches will help.  By themselves, they won't do much.

--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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web