Re: [TAPSETS] Linux Kernel Event Trace Tool

["Guanglei Li" <guanglei at cn dot ibm dot com>]

----- Original Message ----- 
From: "Guanglei Li" <guanglei@cn.ibm.com>
To: "Mathieu Desnoyers" <compudj@krystal.dyndns.org>
Cc: <systemtap@sourceware.org>; <jrs@us.ibm.com>
Sent: Sunday, December 18, 2005 8:59 PM
Subject: Re: [TAPSETS] Linux Kernel Event Trace Tool


> >  Mathieu:
> > Just to throw some ideas :
> >
> > Which protection against concurrency between multiple data sources 
> > do you use
> > (SMP, process vs interrupt) ?
> >
> > I have looked at the CVS SystemTAP code : the _stp_printk function 
> > is all but
> > atomic.
>
> [...]
> Anyway, I think systemtap itself should handle the concurrency 
> issue. Am I right?
after thinking Mathieu's idea again, the touble may happen if a probe 
handler makes mutiple calls to _stp_printf and during its execution, 
it is migrated to another CPU.
_stp_printf will get the current CPU id every time it is called.

If calling _stp_printf only one time in the probe handler, such issues 
should be avoid. Am I right?

and after looked into the generated c code (stap -p3), I saw that 
_stp_print_flush() will be called at the end of every probe handler. 
the comments of _stp_print_flush() says this is a must. But each probe 
handler of my tapsets will print only a single row of data. calling 
_stp_print_flush() for every single line of data will be expensive. 
Any way to avoid this? such as not calling _stp_printf at end of probe 
handlers. The print buffer of each cpu is 8K which could be able to 
holds lots of lines of data.