linux-kernel - Re: [RFC][PATCH] tracepoints: Move the work out of line from hotpath sections

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:	Thu, 09 Aug 2012 18:25:31 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Avi Kivity <avi@...hat.com>,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC][PATCH] tracepoints: Move the work out of line from
 hotpath sections

On Thu, 2012-08-09 at 16:50 -0400, Mathieu Desnoyers wrote:

> I guess the very first thing to do would be to benchmark this patch
> thoroughly to see if it brings significant performance improvements to
> the "tracing built-in, not enabled" case. If it does bring a significant
> improvement, then we can consider the overhead on tracing, and see if it
> makes sense to add this extra indirection on the tracing hot path.

I know you and your customers focus a lot on tracing. But if there is a
decent improvement with the 'off' case, then I think that's rational
enough for such a change. Remember, tracing is always a second class
citizen to kernel performance.

But I agree that this change is probably not worth it if it's just a
slight performance.

> 
> About your "Pro" point "Less code in the hot paths", it remains to be
> seen, overall, how many bytes of the removed instructions actually sit
> on hot cache lines and if there is any effect on the TLB, especially
> given that this "maybe-not-so-hot" code is in an unlikely branch.

This is why I posted the patch now. I don't have any real good
measurements for performance testing. It showed some improvement with
hackbench, but hackbench is very unreliable for such tests. I'm hoping
others will run it under their work loads to see how things improve.

> 
> It might be better to improve gcc to move really cold branches out of
> line (really, really far away), and use the compiler to do this, rather
> than to use an extra indirection that adds bloat and complexity to the
> kernel.

I think modifying gcc is something that can help more than tracing. But
that's been a pipe dream for such a long time that I've started dreaming
about winning a gold medal in the Olympics instead. Standing on the
podium listening to the crowd chanting your name along with your country
is more fun to dream about than seeing your unlikely code stop becoming
hurdles for the CPU sprinters.

Yes, I had a bit of Olympic overdose lately.

-- Steve

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