On 08/30/10 10:17 AM, Jonathan Adams wrote:
On Fri, Aug 27, 2010 at 04:44:31PM -0700, Rafael Vanoni wrote:
I was trying to aggregate on the stack trace of a CPU's current
thread from a cpu_t * and the best I could do was aggregating with
sym() on the t_startpc field of the CPU's curr
I was trying to aggregate on the stack trace of a CPU's current thread
from a cpu_t * and the best I could do was aggregating with sym() on the
t_startpc field of the CPU's current thread.
It doesn't look like it would be very difficult to write a new action to
get stack() from a given CPU id.
Hi folks
I'm running into these errors after adding a group_t to the CPU structure:
/export/rafael/test/proto/root_i386/usr/include/sys/cpuvar.h:237: error:
field `cpu_new_field' has incomplete type
dmake: Warning: Command failed for target `pics/dt_lex.o'
/export/rafael/test/proto/root_i386/u
Rafael Vanoni wrote:
On Thu, Dec 3, 2009 at 10:07 PM, Kevin Fitch wrote:
I have a situation that I would like to debug with dtrace, but I am
not sure
how.
I have a process that kicks off, runs for a few seconds (perhaps
milliseconds) then goes away. And this happens very frequently, think
On Thu, Dec 3, 2009 at 10:07 PM, Kevin Fitch wrote:
I have a situation that I would like to debug with dtrace, but I am not sure
how.
I have a process that kicks off, runs for a few seconds (perhaps
milliseconds) then goes away. And this happens very frequently, think
old-school CGI based web a
m...@bruningsystems.com wrote:
Allan wrote:
Rafael
Thanks for the update I will be looking to implement the changes.
Can you advise on the benefit of changing the nosteal_nsec vs
rechoose_interval , my thoughts were if the rechoose interval was
increased to an amount larger than the time spent
Allan wrote:
Hi,
I am looking to measure how long a thread takes to migrate between cpu's and how often , what I have is below which is checking just one process is this the correct track to be on here?
My aim is to look at a process and look at upping the reboose_interval on some
of our se
I've noticed different behaviors on x86 and sun4v when walking an
aggregation, specifically with the data type used to cast the memory
position at which agg data resides. For instance, the following snippet
from a walker works correctly on x86 but not on sun4v:
dtrace_aggdesc_t
Pankaj wrote:
I am new-bie in this world of unix..
just wanted to know that if DTrace uses any hardware support for its function.
thanks in advance
No, DTrace doesn't require any hardware support. Just to help clarify,
DTrace is an observability framework that allows you to trace software
ev
Jonathan Adams wrote:
On Tue, Jun 16, 2009 at 01:32:29PM -0300, Rafael Vanoni wrote:
Jonathan Adams wrote:
# dtrace -n'
fbt::kmem_alloc:return
/((uintptr_t)caller - (uintptr_t)&`poll_common) < sizeof
(`poll_common)/
{stack()}
'
(replace kmem_alloc and pol
Jonathan Adams wrote:
# dtrace -n'
fbt::kmem_alloc:return
/((uintptr_t)caller - (uintptr_t)&`poll_common) < sizeof (`poll_common)/
{stack()}
'
(replace kmem_alloc and poll_common with the functions of interest, of course)
Cheers,
- jonathan
Ah, very cool. Didn't know about caller.
rickey c weisner wrote:
Let me try this again.
I want a predicate such that if my probe is
fbt::foo:entry
the predicate will only fire if the parent of foo is foobar.
Now I am already in foobar, I have been there for minutes.
I want to see what is happenning underneath foobar.
I can not set a
Michael Schuster wrote:
On 05/29/09 08:45, Peter Jones wrote:
I'm in the process of writing a daemon that uses libdtrace to collect
performance data continuously. The only real problem I've run into is
figuring out how to limit the amount of data I'm collecting.
I obviously don't need to know
Adam Leventhal wrote:
Hi Rafael,
What bits are you trying this on? I suggest you try to whittle this
script down to the smallest version you can that reproduces a similar
failure. From there, we can help diagnose the problem.
Adam
Hi Adam
Here's a simpler example. I'm running OpenSolaris snv
Running into a strange error with powertop(1). The script below, which
worked until snv_107, fails with the following error
r...@catfish:~$ dtrace -s /tmp/freq.d
dtrace: failed to compile script /tmp/freq.d: line 13: last[ ] key #1 is
incompatible with prototype:
prototype: int
I've been looking at the probe points for sysinfo:::xcalls and I'm
wondering if the point for xc_capture_cpus() is correct.
There's two points for this probe on x86, in xc_capture_cpus() and
xc_common(). The latter fires syinfo:::xcalls for each invocation of
send_dirint(). But xc_capture_cpus(
Chad Mynhier wrote:
> On Tue, Aug 26, 2008 at 2:24 PM, Rafael Vanoni <[EMAIL PROTECTED]> wrote:
>> Hi all
>>
>> There was recently a couple of emails at tesla-dev pointing out that
>> PowerTOP(1) and intrstat(1M) show 0'ed values after resuming - both are
Hi all
There was recently a couple of emails at tesla-dev pointing out that
PowerTOP(1) and intrstat(1M) show 0'ed values after resuming - both are
libdtrace(3LIB) consumers.
I haven't found a bug against this issue, but unfortunately I'm having a
bit of a hard time finding a system that suppo
Chad Mynhier wrote:
> On Fri, Jul 25, 2008 at 3:08 PM, chris kiick <[EMAIL PROTECTED]> wrote:
>> On Fri, Jul 25, 2008 at 03:05:06PM -0500, Chad Mynhier wrote:
>>> Chris, have you filed a bug for this? If not, I can do so. If so,
>>> could you give me the number?
>>>
>>> Thanks,
>>> Chad
>> Hot of
ven probe ?
> I've been meaning to write up a blog entry describing how USDT works, but
> I've been afraid that only James McIlree and I would find it interesting.
I would too :)
Rafael
>
> Adam
>
> On Mon, Jun 16, 2008 at 09:34:26PM +0100, Rafael Vanoni wrote:
>>
I was looking at some assembly on mdb and noticed that calls to
DTRACE_PROBE1() were seen as ~5 nops.
Could anyone explain me why's that ?
thanks
Rafael
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Aubrey Li wrote:
> On Tue, May 20, 2008 at 12:26 AM, Bryan Cantrill <[EMAIL PROTECTED]> wrote:
>>> I've got an app that periodically runs dtrace scripts through libdtrace
>>> and am seeing a good amount of xcalls from that.
>>>
>>> I understand why dtrace uses xcalls, so this is an expected behavio
Hi all
I've got an app that periodically runs dtrace scripts through libdtrace
and am seeing a good amount of xcalls from that.
I understand why dtrace uses xcalls, so this is an expected behavior to
a certain extent. But because my app repeats the scripts on an interval
basis, the amount of x
23 matches
Mail list logo
