Is there a way (with -w) to do pause/resume within kernel probes to aid in reproducing timing issues. So thread 1 would do something like pause(cond) and thread 2 would do resume(cond). Thanks, Mike
There is the chill() action, which allows you to induce arbitrary delay
(up to a maximum limit). See:
http://docs.sun.com/app/docs/doc/817-6223/6mlkidlhl?a=view
You can also stop processes using the stop() action, and resume them
using ''system("prun %d")''.
- Eric
On Wed, Aug 10, 2005 at 03:00:43PM -0700, Michael Bergknoff
wrote:> Is there a way (with -w) to do pause/resume within kernel probes to aid
> in reproducing timing issues. So thread 1 would do something like
> pause(cond) and thread 2 would do resume(cond).
>
> Thanks,
> Mike
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
--
Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
I believe the chill() function in a probe''s actions does what you ask. Dan
Eric Schrock wrote:> There is the chill() action, which allows you to induce arbitrary delay > (up to a maximum limit). See: > > http://docs.sun.com/app/docs/doc/817-6223/6mlkidlhl?a=view > > You can also stop processes using the stop() action, and resume them > using ''system("prun %d")''. > > - EricI should have mentioned that I looked into chill but the manual said it''s not safe to chill for more than a few hundred milliseconds due to issues with interrupts in the probed context. I''m looking at starting one thread and pausing for minutes before resuming in another thread. As for stop() I believe that stops on the way out of the kernel which is not what I need. Thanks, Mike
On Wed, Aug 10, 2005 at 04:27:30PM -0700, Michael Bergknoff wrote:> > I should have mentioned that I looked into chill but the manual said > it''s not safe to chill for more than a few hundred milliseconds due to > issues with interrupts in the probed context. I''m looking at starting > one thread and pausing for minutes before resuming in another thread. As > for stop() I believe that stops on the way out of the kernel which is > not what I need. >Yes, stop() will stop the process on the way out of the kernel. There is no way to allow for the behavior you describe in arbitrary probe context. Your only bet here is probably a custom kernel. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
On Wed, Aug 10, 2005 at 04:27:30PM -0700, Michael Bergknoff wrote:> I should have mentioned that I looked into chill but the manual said > it''s not safe to chill for more than a few hundred milliseconds due to > issues with interrupts in the probed context. I''m looking at starting > one thread and pausing for minutes before resuming in another thread. As > for stop() I believe that stops on the way out of the kernel which is > not what I need.We don''t let you stop a thread at an arbitrary place in the kernel because it simply isn''t safe. For example, you could end up backing up the entire system on some kernel mutex which the stopped thread holds, and there would be no way to restart the system. Even less than arbitrary freedom to stop thread in the kernel would be difficult to implement in a provably safe manner. Adam -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
Michael Bergknoff wrote: ...> I should have mentioned that I looked into chill but the manual said > it''s not safe to chill for more than a few hundred milliseconds due to > issues with interrupts in the probed context. I''m looking at starting > one thread and pausing for minutes before resuming in another thread. As > for stop() I believe that stops on the way out of the kernel which is > not what I need.Then clearly you''ve got some serious constraints to work under. I don''t envy you :) What problem are you trying to solve? James C. McPherson -- Pacrim PTS Engineer 828 Pacific Highway Gordon NSW Sun Microsystems Australia 2072