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
| ||
|
Date: Wed, 17 Nov 2010 14:02:22 -0500 From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com> To: Tom Zanussi <tzanussi@...il.com> Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...e.hu>, Ted Ts'o <tytso@....edu>, Thomas Gleixner <tglx@...utronix.de>, LKML <linux-kernel@...r.kernel.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Andrew Morton <akpm@...ux-foundation.org>, Steven Rostedt <rostedt@...dmis.org>, Arjan van de Ven <arjan@...radead.org>, Arnaldo Carvalho de Melo <acme@...hat.com>, Frederic Weisbecker <fweisbec@...il.com>, Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>, Li Zefan <lizf@...fujitsu.com>, Jason Baron <jbaron@...hat.com>, "David S. Miller" <davem@...emloft.net>, Christoph Hellwig <hch@....de>, Pekka Enberg <penberg@...nel.org>, Lai Jiangshan <laijs@...fujitsu.com>, Eric Dumazet <eric.dumazet@...il.com> Subject: Re: [ANNOUNCE] New utility: 'trace' * Tom Zanussi (tzanussi@...il.com) wrote: > On Wed, 2010-11-17 at 13:36 -0500, Mathieu Desnoyers wrote: > > * Tom Zanussi (tzanussi@...il.com) wrote: > > [...] > > > IIRC, I think the conclusion we came to was that it could be done > > > mechanically if for example the right-hand-side of an assignment in > > > TP_fast_assign() only involved a simple variable assignment, but as > > > Steve pointed out, some assignments are more complicated than that. > > > > Yep, we came up to the same conclusions in UST. > > > > > For example, in the sched_switch tracepoint assignments: > > > > > > __entry->prev_prio = prev->prio; > > > __entry->prev_state = __trace_sched_switch_state(prev); > > > > > > so the prev_prio should be able to be tested 'in-line' but the > > > prev_state would require a temporary buffer to write the value into > > > before doing the test as mentioned by Steve. At which point you're no > > > further ahead (in that case) than the current situation... > > > > if we change all assignments to, e.g.: > > > > _tp_assign(__entry->prev_prio, prev->prio) > > _tp_assign(__entry->prev_state, __trace_sched_switch_state(prev)) > > > > then we can redefine the macros for filtering much more easily than with the > > " = " assignment operator. > > > > About your comment above, what is the problem with evaluating > > "__trace_sched_switch_state(prev)" twice ? It will typically be cache-hot after > > the first evaluation, so I wonder if, in practice, we really save a significant > > amount of cycles by saving its result between filtering and writing into trace > > buffers. As I pointed out earlier, for my customers, having a very, very fast > > filter "out" case is more important that trying to squeeze a few cycles out of > > the filter passed case. > > > > But the idea is to avoid allocating the trace buffer in the first place, > until we've decided we want the event. So how do you check the result > of __trace_sched_switch_state(prev) with the filter value if you don't > have it temporarily stored somewhere (not in the trace buffer, which > doesn't exist yet as far as this event is concerned)? It seems I might be missing something important, but what's wrong with using registers or the stack to hold the value for comparison ? In this case, it's a "long", so a register seems perfectly reasonable. But again, I feel I'm missing a key point -- what is it ? Thanks, Mathieu > > Tom > > > Also, how many of these "__trace_sched_switch_state(prev)" are static inlines vs > > actual function calls ? If it's mostly static inlines to dereference a few > > pointers, doing it the second time when the filter passed won't hurt much. > > > > Thanks, > > > > Mathieu > > > > -- 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/
Powered by blists - more mailing lists