headers
jkenisto at us dot ibm dot com | 1 Jul 2006 01:35
Favicon

[Bug kprobes/2062] Return probes does not scale well on SMP box


------- Additional Comments From jkenisto at us dot ibm dot com  2006-06-30 23:35 -------
Created an attachment (id=1132)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=1132&action=view)
Finer-grained locking for kretprobes

Here's a mostly-untested, i386-only patch that I put together in my spare time
quite a while ago.  I meant to test it on an SMP system before posting it, but
I haven't found the time.  But I don't want the work to go to waste, so here it
is.  The patch is described in its preamble.

--

-- 

http://sourceware.org/bugzilla/show_bug.cgi?id=2062

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 0 comments |
headers
fche | 1 Jul 2006 16:27
Favicon

new systemtap snapshot available

A new automated systemtap CVS snapshot is available.
ftp://sources.redhat.com/pub/systemtap/snapshots/systemtap-20060701.tar.bz2
483394 bytes
Permalink | Reply | 0 comments |
headers
Li Guanglei | 2 Jul 2006 16:05
Picon
Favicon

Re: Question about stpd and install directory

Frank Ch. Eigler ??:
>> I just installed system tap from CVS, configured with:
>>> ./configure --with-elfutils=/local/src/elfutils-0.121/
>>> --prefix=/local/systemtap
>> Note the non-default install directory.
>> [...]
>> Is there an option I should be passing to stap to find the right
>> stpd location?
>> [...]
> 
> Something is strange here.  With my builds (using only --prefix),
> the Makefile properly passes the resultant  <at> pkglibdir <at>  along:
> 
> [...]
> if g++ -DHAVE_CONFIG_H -I. -I../src -I. 
-DPKGLIBDIR='"/home/fche/Private/DEVEL/DEVEL-systemtap/BUILD/../INST/libexec/systemtap"'
-DPKGDATADIR='"/home/fche/Private/DEVEL/DEVEL-systemtap/BUILD/../INST/share/systemtap"'
-Iinclude-elfutils  -Werror -Wall -g -O2 -MT stap-buildrun.o -MD -MP -MF ".deps/stap-buildrun.Tpo" -c
-o stap-buildrun.o `test -f 'buildrun.cxx' || echo '../src/'`buildrun.cxx; \
> then mv -f ".deps/stap-buildrun.Tpo" ".deps/stap-buildrun.Po"; else rm -f
".deps/stap-buildrun.Tpo"; exit 1; fi
> [...]
> 
> It is that PKGLIBDIR macro that is used in buildrun.cxx in order to
> find stpd.  What does it say in your builds?
> 
> 
> - FChE

I tried and found if you get a fresh new codes from cvs and then
(Continue reading)

Permalink | Reply | 0 comments |
headers
bibo, mao | 3 Jul 2006 04:37
Picon
Favicon

[PATCH] IA64 kprobe invalidate icache of jump buffer

Hi,

   Kprobe inserts breakpoint instruction in probepoint and then jumps
to instruction slot when breakpoint is hit, the instruction slot icache
must be consistent with dcache. Here is the patch which invalidates
instruction slot icache area.
   Without this patch, in some machines there will be fault when executing
instruction slot where icache content is inconsistent with dcache.This patch
is based on 2.6.17 version.	

Signed-off-by: bibo,mao <bibo.mao <at> intel.com>

thanks
bibo,mao          

 arch/ia64/kernel/kprobes.c    |    9 +++++++++
 include/asm-i386/kprobes.h    |    1 +
 include/asm-ia64/kprobes.h    |    1 +
 include/asm-powerpc/kprobes.h |    1 +
 include/asm-sparc64/kprobes.h |    1 +
 include/asm-x86_64/kprobes.h  |    1 +
 kernel/kprobes.c              |    1 +
 7 files changed, 15 insertions(+)

----------------------------------------------------------------------------
diff -Nruap 2.6.17.org/arch/ia64/kernel/kprobes.c 2.6.17/arch/ia64/kernel/kprobes.c
--- 2.6.17.org/arch/ia64/kernel/kprobes.c	2006-06-29 03:50:15.000000000 +0800
+++ 2.6.17/arch/ia64/kernel/kprobes.c	2006-07-03 02:43:16.000000000 +0800
 <at>  <at>  -449,11 +449,20  <at>  <at>  int __kprobes arch_prepare_kprobe(struct
 	return 0;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Li Guanglei | 3 Jul 2006 11:22
Picon
Favicon

Re: Any post performance analyzer tool suitable for LKET ?

Hien Nguyen 写道:
> We plan to add the visual analyzer to the SystemTap GUI. I would love to
> get the hold of your trace data (binary or ascii) to start with.
> 
> Thanks, Hien.
> 

Great. A visual analyzer is really important for LKET considering such
a large volume trace data. The lket(5) man page have a section of
event hooks and their data format. I added a moment ago the
descriptions of some event hooks used internally by LKET, such as
event registering hooks, process snapshot event hook. I will try to
keep the man page up to date.

Feel free to ask me for any suggestion and comment.

Thanks.

- Guanglei
Permalink | Reply | 0 comments |
headers
Nathan DeBardeleben | 3 Jul 2006 19:44

Re: SystemTap GUI


-- Nathan
Correspondence
---------------------------------------------------------------------
Nathan DeBardeleben, Ph.D.
Los Alamos National Laboratory
Parallel Tools Team
High Performance Computing Environments
phone: 505-667-3428
email: ndebard <at> lanl.gov
---------------------------------------------------------------------

Ryan Morse wrote:
> We recently posted the code for the Systemtap GUI on Souceforge under 
> an EPL license.
>
> http://stapgui.sourceforge.net/
> http://sourceforge.net/projects/stapgui/
>
> There are two different versions of the code, a pre-built version or a 
> source version.  The pre-built version, while larger, contains 
> everything needed and ready to run.  The source version requires 
> eclipse to build it into an executable.  There are instructions for 
> building both versions contained in the tarballs in the documentation 
> folder.
>
> Currently the GUI has two perspectives.  A working IDE Perspective to 
> ease users in creating scripts.  As well as a Graphics Perspective 
> that generates graphs from running scripts.  A full feature list is 
> included in the readme file.  We also are aware of some bugs (listed
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nathan DeBardeleben | 3 Jul 2006 19:45

Re: SystemTap GUI

Laugh, sorry about that last one.  Ryan - is the GUI an Eclipse Rich 
Client Platform application?  Just curious.  It looks to be.

-- Nathan
Correspondence
---------------------------------------------------------------------
Nathan DeBardeleben, Ph.D.
Los Alamos National Laboratory
Parallel Tools Team
High Performance Computing Environments
phone: 505-667-3428
email: ndebard <at> lanl.gov
---------------------------------------------------------------------

Ryan Morse wrote:
> We recently posted the code for the Systemtap GUI on Souceforge under 
> an EPL license.
>
> http://stapgui.sourceforge.net/
> http://sourceforge.net/projects/stapgui/
>
> There are two different versions of the code, a pre-built version or a 
> source version.  The pre-built version, while larger, contains 
> everything needed and ready to run.  The source version requires 
> eclipse to build it into an executable.  There are instructions for 
> building both versions contained in the tarballs in the documentation 
> folder.
>
> Currently the GUI has two perspectives.  A working IDE Perspective to 
> ease users in creating scripts.  As well as a Graphics Perspective
(Continue reading)

Permalink | Reply | 1 comment |
headers
Manoj S Pattabhiraman | 4 Jul 2006 10:35
Picon

Systemtap probe for Signals

Hi,

I just started of with trying systemtap by probing on signal handling.
Those probes are now consolidated under signal.stp.

(See attached file: signal.stp)

Please lemme know your suggestions on the same and how to go forward.

Thanks & Regards,    Manoj
-------------------------------------------------------------------
Manoj S Pattabhiraman, e-mail: mpattabh <at> in.ibm.com
Attachment (signal.stp): application/octet-stream, 2744 bytes
Permalink | Reply | 1 comment |
headers
Li Guanglei | 4 Jul 2006 11:29
Picon
Favicon

Re: Systemtap probe for Signals

Manoj S Pattabhiraman ??:
> Hi,
> 
> I just started of with trying systemtap by probing on signal handling.
> Those probes are now consolidated under signal.stp.
> 
> (See attached file: signal.stp)
> 
> Please lemme know your suggestions on the same and how to go forward.
> 
> Thanks & Regards,    Manoj
> -------------------------------------------------------------------
> Manoj S Pattabhiraman, e-mail: mpattabh <at> in.ibm.com

There are some signal related probes defined in process.stp, they are:
process.signal_send, process.signal_handle, _process.signal_send.part[1-3]

Should we put all signal related probes(excluding signal related 
syscalls) into a separate stp file, say, signal.stp?

some comments of your stp script:

You defined:
  probe signal.sendsig = kernel.function("send_signal")
But should we include kernel.function("send_group_sigqueue") and 
kernel.function("send_sigqueue") into signal.sendsig?

I don't think "probe signal.ignored" matches what it states in the 
comment. It's used to return the status whether a signal has been 
ignored. There is a similar function named is_ignored.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Li Guanglei | 4 Jul 2006 15:02
Picon
Favicon

Re: Systemtap probe for Signals

Manoj S Pattabhiraman ??:
> 
>  I wish it would be better to have a separate stp file for signal 
> subsystem.        
So do I.

>  > I don't think "probe signal.ignored" [...]
> Accepted. I would rather add a return probe point for the above 
> mentioned function. Is that fine.
Yes, a return probe is necessary
> 
> Thanks
> 
> Manoj

- Guanglei
Permalink | Reply | 0 comments |

Gmane