linux-kernel - Re: [PATCH RFC 00/11] lock monitor: Separate features related to lock

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]

Message-ID: <20100319012337.GA22095@nowhere>
Date:	Fri, 19 Mar 2010 02:23:41 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:	Hitoshi Mitake <mitake@....info.waseda.ac.jp>,
	Jason Baron <jbaron@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, h.mitake@...il.com,
	Paul Mackerras <paulus@...ba.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Jens Axboe <jens.axboe@...cle.com>
Subject: Re: [PATCH RFC 00/11] lock monitor: Separate features related to
	lock

On Thu, Mar 18, 2010 at 09:08:57PM -0400, Mathieu Desnoyers wrote:
> > I sometimes wonder which trick between jmp optimization and hot patching
> > would be the best to optimize the tracepoints off-cases.
> > 
> > I should look more closely at the jmp optimization. I don't know if
> > it avoids to push the tracepoints parameters in the off case, in
> > which case it could be perhaps more efficient than hot patching,
> 
> yep, tracepoints with jump patching will branch over the whole stack setup in
> the off case, which is one of the good reasons for using this solution over
> patching only a call (leaving the stack setup in place).



Ok that's good to know. It's a pretty good argument against hot
patching in this particular case.


 
> Note that if the parameters include side-effects (such as a function call),
> these will be executed even when the tracepoint is disabled. This is why people
> should implement these calls with side-effects in the appropriate TRACE_EVENT
> fields.


Good to know too.
But this makes me curious. So it guarantees stack setup won't happen but
can't sort it out with functions as parameters or so?

I have no idea how this thing works. Please Cc me for the next batch,
this looks like a cool thing :)



> > although perhaps most of the time the given arguments are already in
> > registers because the traced function uses them for its own needs.
> > 
> > Also, adopting hot patching means the tracepoint calls would be
> > in a non-inlined separated function. The result would be probably
> > less i-cache footprint from the caller, and better for the off-case,
> > worse for the on-case. But tracing off-case is most important.
> > 
> > (Adding more people in Cc)
> > 
> 
> The idea has been discussed to add support in gcc to emit the code for an
> unlikely branch into a separate section, which does have the smaller cache-line
> footprint benefit your are talking about, but without the overhead of the extra
> out-of-line function call in the enabled case. I don't know how this work is
> advanced though. We had determined that the "asm goto" was an higher priority
> item.


Ok.

Thanks!

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