From: Ingo Molnar <mingo@kernel.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Steven Rostedt <rostedt@goodmis.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Andy Lutomirski <luto@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 1/2] x86/nmi: Optimize the check for being in the repeat_nmi code
Date: Fri, 10 Mar 2017 08:20:56 +0100 [thread overview]
Message-ID: <20170310072056.GA3762@gmail.com> (raw)
In-Reply-To: <CALCETrUFE0X89bmsO8-tcOjPgPXTVCM1URUSD+HaEsGesfq6XA@mail.gmail.com>
* Andy Lutomirski <luto@amacapital.net> wrote:
> > It had nothing to do with speedup. Linus said that the current code makes the
> > assembly programmer in him die a little. I want to cure that.
>
> One might argue that the world would be a better place if the assembly
> programmer in some people died a little.
Joking aside, I'll bite: while in the kernel we try to avoid ever actually
_writing_ new assembly code, assembly programming is still an invaluable skill,
because it indirectly improves all the other 99% of non-assembly .c code:
- Looking at the C compiler's assembly output tells us how close the code is to
optimal.
- Being able to tell whether our C abstractions are too far removed from how the
compiler will map it to machine instructions is invaluable.
- Being able to shape data structures and code in a machine-friendly way.
Much would be lost if the assembly programmer went extinct and it's no
accident that annotated assembly output is just two <Enter> keys away
after launching 'perf top' or 'perf report'. The more developers know
assembly the better, IMHO.
Thanks,
Ingo
next prev parent reply other threads:[~2017-03-10 7:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-09 22:42 [PATCH 0/2] x86/nmi: Optimize address compares with better jump algorithm Steven Rostedt
2017-03-09 22:42 ` [PATCH 1/2] x86/nmi: Optimize the check for being in the repeat_nmi code Steven Rostedt
2017-03-10 2:42 ` Andy Lutomirski
2017-03-10 3:49 ` Steven Rostedt
2017-03-10 3:50 ` Andy Lutomirski
2017-03-10 7:20 ` Ingo Molnar [this message]
2017-03-10 19:00 ` Linus Torvalds
2017-03-10 19:03 ` Andy Lutomirski
2017-03-09 22:42 ` [PATCH 2/2] x86/nmi: Fix and optimize the NMI stack check code Steven Rostedt
2017-03-10 2:43 ` Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170310072056.GA3762@gmail.com \
--to=mingo@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.