headers
jistone at redhat dot com | 1 Mar 2009 01:55
Favicon

[Bug translator/6932] c->busy can be non-atomic.


------- Additional Comments From jistone at redhat dot com  2009-03-01 00:55 -------
(In reply to comment #14)
> If we can't find any measurement that show a meaningful improvement
> due to this patch, I'd rather not take the risk that we're forgetting
> some barrier or other, and leave the code as is.

I don't think that atomic operations will guarantee memory order either, so
we're probably already missing barriers...

--

-- 

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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 0 comments |
headers
beginner966 | 1 Mar 2009 12:11
Picon

Script run makes the system to hang


Hi all,

I had written this script to gather the time spent by a task in the
runqueue. It runs fine for 1-2 ms or so(short time I mean). But whenever I
try to run it without an exit() in timer function, my system hangs.
Please suggest some help regarding this matter as to how to make this script
run for infinite amount of time and provide useful statistics.

#!/usr/bin/env stap  

/*
 * Global variable declaration
 */ 

global runqueuetime
global runnabletime
global cputime
global oncputime
global tstamp
global names
global start

probe timer.ms(11)
{
	exit();
}

probe kernel.function("finish_task_switch")
{
(Continue reading)

Permalink | Reply | 5 comments |
headers
dsmith at redhat dot com | 2 Mar 2009 15:55
Favicon

[Bug tapsets/6525] need utrace task-finder-based pid->execname, pid->cwd-path-name tables


------- Additional Comments From dsmith at redhat dot com  2009-03-02 14:55 -------
(In reply to comment #5)
> I once tried to implement the functions using task_finder. The basic code is
> like the following
> 
> #include "task_finder.c"
> static char _stp_taskname[TASK_COMM_LEN]="";
> static int _stp_process_search_cb(struct stap_task_finder_target *tgt, struct
> task_struct *tsk, int register_p, int process_p) {
>   if (register_p) { /* found one match */
>         if (tsk == NULL) {
>                 strlcpy(_stp_taskname, "UNKNOWN", MAXSTRINGLEN);
>                 return 1;
>         } else {
>                 strlcpy(_stp_taskname, tsk->comm, MAXSTRINGLEN);
>                 return 0;
>         }
>   }
>   return 1;
> }
> 
> function pid2execname2:string(pid:long) %{ /* pure */
>         struct stap_task_finder_target tgt;
>         tgt.pathname = NULL;
>         tgt.pid = (pid_t)(long)THIS->pid;
>         tgt.callback = &_stp_process_search_cb;
>         tgt.vm_callback = NULL;
>         stap_register_task_finder_target(&tgt);
>         stap_start_task_finder();
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Ch. Eigler | 2 Mar 2009 19:44
Picon
Favicon
Gravatar

Re: Script run makes the system to hang


beginner966 <nitin966 <at> gmail.com> writes:

> I had written this script to gather the time spent by a task in the
> runqueue. It runs fine for 1-2 ms or so(short time I mean). But
> whenever I try to run it without an exit() in timer function, my
> system hangs. [...]

Can you collect the information suggested by the HowToReportBugs systemtap
wiki page and/or by running the "stap-report" script?

> Please suggest some help regarding this matter as to how to make this script
> run for infinite amount of time and provide useful statistics.
> probe timer.ms(11)
> {
> 	exit();
> }

(Please note that 11 milliseconds is a very short time indeed.)

> probe kernel.function("finish_task_switch") [...]

I wonder if utrace-based or scheduler.stp tapset-based probe points
may serve as well.

- FChE
Permalink | Reply | 4 comments |
headers
Maynard Johnson | 2 Mar 2009 22:46
Picon
Favicon

[PATCH] Fix compilation errors for itrace probe point

Hello,
I recently pulled down the systemtap src onto a Fedora 10 system and tried to use the itrace probe point.  The
resulting kernel module failed to compile because the runtime/itrace.c file had not been updated to
reflect the recent utrace interface changes.  This problem had not been caught because the itrace test is
currently disabled (since it fails on x86_64).  I am working on the itrace test problem and will post a
separate patch when I have it resolved.  The patch attached to this message addresses mainly the utrace
interface changes, but also includes a couple other minor unrelated fixes (e.g., removing unnecessary
#includes in runtime/itrace.c and adding a #include for task_finder.c in tapsets.cxx).  With this
patch, the  kernel module with itrace probe point compiles OK on x86_64; ho
 wever, there is another compilation issue on ppc64 which I will post a separate note about.

NOTE:  When I pulled systemtap today (using git clone git://sources.redhat.com/git/systemtap.git) to
make sure my patch applied cleanly to current code, there were no ChangeLog files in the src tree.  There
were ChangeLogs in the tree that I pulled down a few weeks ago.  Did something change in the process that I
didn't catch?

Thanks for your time in reviewing this patch.

-Maynard
Attachment (systap-utrace2.patch): text/x-patch, 6687 bytes
Permalink | Reply | 6 comments |
headers
Josh Stone | 2 Mar 2009 23:15
Picon
Favicon
Gravatar

Re: [PATCH] Fix compilation errors for itrace probe point

Maynard Johnson wrote:
> NOTE:  When I pulled systemtap today (using git clone git://sources.redhat.com/git/systemtap.git) to
make sure my patch applied cleanly to current code, there were no ChangeLog files in the src tree.  There
were ChangeLogs in the tree that I pulled down a few weeks ago.  Did something change in the process that I
didn't catch?

Right -- the ChangeLogs were becoming a pain point in the git workflow, 
frequently causing broken merges, etc.  We now simply include all 
relevant information in the commit message, so "git log" should give you 
all the change history you need.

Josh
Permalink | Reply | 0 comments |
headers
Maynard Johnson | 3 Mar 2009 00:47
Picon
Favicon

[PATCH RFC] itrace probe point problem on ppc64: unknown symbol 'access_process_vm'

Hi,
As I mentioned in my previous post today, besides the need for updating runtime/itrace.c to use the new
utrace interface, I found another problem when trying to use the itrace probe point on ppc64 -- I got an
"unknown symbol" error for 'access_process_vm' when systemtap tried to insert the generated kernel
module.  Turns out that on the ppc64 kernel for Fedora, this symbol isn't exported.  :-(  I've gotten around
this by simply pasting the access_process_vm code into runtime/itrace.c and renaming it to avoid a clash
when using on Fedora/x86_64 (where this kernel function *is* exported).  The attached patch shows this
change.  Is this an acceptable way to handle this problem?  Or does someone have a better idea?

Thanks.
-Maynard
Attachment (systap-access_process_vm.patch): text/x-patch, 2562 bytes
Permalink | Reply | 1 comment |
headers
Frank Ch. Eigler | 3 Mar 2009 01:16
Picon
Favicon
Gravatar

Re: [PATCH RFC] itrace probe point problem on ppc64: unknown symbol 'access_process_vm'

Maynard Johnson <maynardj <at> us.ibm.com> writes:

> [...]  -- I got an "unknown symbol" error for 'access_process_vm'
> when systemtap tried to insert the generated kernel module.  Turns
> out that on the ppc64 kernel for Fedora, this symbol isn't exported.
> [...]

Yeah, see runtime/uprobes*/uprobes.c: __access_process_vm().

- FChE
Permalink | Reply | 0 comments |
headers
fche at redhat dot com | 3 Mar 2009 05:07
Favicon

[Bug translator/6932] c->busy can be non-atomic.


------- Additional Comments From fche at redhat dot com  2009-03-03 04:07 -------
> I don't think that atomic operations will guarantee memory order either, so
> we're probably already missing barriers...

For the "busy" flag, I don't think ordering issues arise if we continue to
use the atomic.h API.  Concurrent reads/writes are SMP-synchronized - that's 
the whole point.  Note that we only write c->fields if the atomic_inc_return
returned the proper value.

--

-- 

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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 0 comments |
headers
wenji dot huang at oracle dot com | 3 Mar 2009 05:29
Favicon

[Bug tapsets/6525] need utrace task-finder-based pid->execname, pid->cwd-path-name tables


------- Additional Comments From wenji dot huang at oracle dot com  2009-03-03 04:29 -------
(In reply to comment #6)
> > But it can't return the execname of most running processes like init, mingetty,
> > kjournald because the callback is never invoked.
> > Only works fine on my forked test process. My box is 2.6.27.9-159.fc10.i686.
> 
> The task_finder will never be able to return the execname or pathname of kernel
> threads, like 'init' or 'kjournald'.  The 'u' in 'utrace' stands for 'user' - it
> only works on user threads.  I'm unsure of why 'mingetty' couldn't be found.
> 
> > Did I miss something or misunderstand the mechanism?
> 
> Besides the above problem of returning the execname/pathname for kernel threads,
> there are other things that won't work well in the code you posted.  As
> currently written, the task_finder isn't designed to register new targets while
> running (since there is no locking provided) or to be started/stopped more than
> once.
> 
Thank you for letting me know this. Seems task_finder is not good candidate
for pid lookup functions. Maybe my patch in #4 is a choice.

--

-- 

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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane