linux-kernel - Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

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:	Fri, 15 Sep 2006 17:02:24 -0500
From:	"Jose R. Santos" <jrs@...ibm.com>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
CC:	Ingo Molnar <mingo@...e.hu>, Roman Zippel <zippel@...ux-m68k.org>,
	Andrew Morton <akpm@...l.org>, tglx@...utronix.de,
	karim@...rsys.com, Paul Mundt <lethal@...ux-sh.org>,
	Jes Sorensen <jes@....com>, linux-kernel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Tom Zanussi <zanussi@...ibm.com>, ltt-dev@...fik.org,
	Michel Dagenais <michel.dagenais@...ymtl.ca>
Subject: Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

Mathieu Desnoyers wrote:
> * Jose R. Santos (jrs@...ibm.com) wrote:
> > To some people performance is the #1 priority and to other it is 
> > flexibility.  I would like to come up with a list of those probe point 
> > that absolutely need to be inserted into the code statically.  Those 
> > that are not absolutely critical to have statically should be 
> > implemented dynamically.
> > 
>
> I agree with you that only very specific parts of the kernel have this kind of
> high throughput. Using kprobes for lower thoughput tracepoints if perfectly
> acceptable from my point of view, as it does not perturb the system too much.
>
> I would suggest (as a beginning) those "standard" hi event rate tracepoints :
>
> (taken from the highest rates in
> http://sourceware.org/ml/systemtap/2005-q4/msg00451.html)
>
> - syscall entry/exit
> - irq entry/exit
> - softirq entry/exit
> - tasklet entry/exit
> - trap entry/exit
> - scheduler change
> - wakeup
> - network traffic (packet in/out)
> - "select" and "poll" system calls
> - page_alloc/page_free
>
> (be warned : this list is probably incomplete, too exhaustive or can cause
> dizziness under stress condition) :)
>
> However, a tracing infrastructure should still provide the ability for
> developers to instrument their own high traffic interrupt handler with a very
> low overhead.
>   
This is base on a single scenario, which is wrong.  A criteria needs to 
be establish that describes the justification for a static trace hook.  
Base on the previous comments on the thread, this list is already seems 
to big.

If a user of the trace tool absolutely need to have the best 
performance, then the propose tool should be smart enough to use static 
hooks if available but revert back to dynamic probes if there is no 
available static counter part.  This performance static tracepoint patch 
can be maintained outside of the kernel tree without bloating the 
kernel.  This way he can have mostly dynamic trace point but at least 
provide some sort of mechanism for those that absolutely must have 
static hooks in order to get useful data out of the trace tool.

-JRS


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