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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrU+qtpSMRj2KZhaZATTa0MPgu08JPJb1p2owwOdzaqJDw@mail.gmail.com>
Date:	Fri, 3 Jul 2015 09:27:11 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Borislav Petkov <bp@...en8.de>, Andy Lutomirski <luto@...nel.org>,
	X86 ML <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Rik van Riel <riel@...hat.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Denys Vlasenko <vda.linux@...glemail.com>,
	Kees Cook <keescook@...omium.org>,
	Brian Gerst <brgerst@...il.com>,
	Paul McKenney <paulmck@...ux.vnet.ibm.com>
Subject: 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@...nel.org> wrote:
>
> * Andy Lutomirski <luto@...capital.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/