linux-kernel - Re: [rfc] x86: optimise page fault path a little

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 14 Nov 2008 03:43:47 +0100
From:	Nick Piggin <npiggin@...e.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andi Kleen <andi@...stfloor.org>, Ingo Molnar <mingo@...e.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [rfc] x86: optimise page fault path a little

On Thu, Nov 13, 2008 at 06:07:45PM -0800, Linus Torvalds wrote:
> 
> 
> On Fri, 14 Nov 2008, Nick Piggin wrote:
> > 
> > True, but is it any better to jam them all into a 300 line function
> > with gotos?
> 
> That wasn't what I was saying.
> 
> Theere are two "good" cases:
> 
>  - don't mess with things.
> 
>    This is good. Stability is good.
> 
>  - Clearly improve things. 
> 
>    This is great.
> 
> And I'll happily do either of the above.
> 
> Your patch had some improvement, but it had some clear not-so-improved 
> parts. That makes it INFERIOR to just leaving things well alone.
> 
> The thing is, I'm not very much interested in just a micro-optimization 
> that seems to be all about just gcc code generation. Long-term, that's 
> just bad.
> 
> But if it's a clear and undeniable _cleanup_, then long-term, it's 
> actually a win. If it also happens to fix some gcc stack allocation issues 
> etc, then that is just gravy.
> 
> See my point? Cleanup is good. But it had better _be_ a cleanup. Random 
> micro-optimization is not so good, especially not if it them makes the 
> code do things that good code simply shouldn't be doing.

It's not a cleanup, it's an optimisation. I just didn't happen to think
it particularly makes the code *less* clean, unlike you. But I'd *never*
try to merge pointless churn like this as a cleanup because I didn't
think the old code was too bad either.

No, it's purely an optimisation. And it is using knowlege of how gcc
generates code to some extent. But adding branch annotations and
out of lining things isn't really something gcc will be able to
do on its own (it could _guess_, or use PGO, and do better register
allocation, I guess).

Anyway, it saves 300 bytes of stack footprint and seems to save a
couple of lines of icache footprint by packing the fastpaths better.

I don't exactly know what you mean by random micro-optimization. It is
what it is. I like counting cachelines and branches and I thought you
did as well.

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