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: <20100319013658.GB28456@Krystal>
Date:	Thu, 18 Mar 2010 21:36:58 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:	Frederic Weisbecker <fweisbec@...il.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

* Frederic Weisbecker (fweisbec@...il.com) wrote:
> 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 :)
> 

Well, the now deceased "Linux Kernel Markers" (which were based on a single
macro rather than static inline functions) were able to use the preprocessor to
put function calls passed as argument within the conditional branch. But with
tracepoints, we rely on static inlines to have flexible parameter declaration,
so this is not possible.

All the arguments passed to the static inline (eventually used for the stack
setup of the actual function call within the tracepoint) can be moved into the
conditional branch by the compiler optimizations, because they are not needed
otherwise. However, this cannot be done for function calls passed as parameter
to the tracepoint, because the compiler do not know whether or not the function
side-effects are needed outside of the "tracing active" branch.

Mathieu

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

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
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/