Every first time to run dtrace command after the system boot up,
It takes a very long time to get response.
But the second time is OK, as follows:
# time dtrace -l /dev/null
real4m8.011s
user0m0.116s
sys 0m2.420s
# time dtrace -l /dev/null
real0m0.632s
user0m0.075s
sys
On Jan 14, 2008 8:52 PM, Sean McGrath - Sun Microsystems Ireland
[EMAIL PROTECTED] wrote:
Aubrey Li stated:
Every first time to run dtrace command after the system boot up,
It takes a very long time to get response.
But the second time is OK, as follows:
# time dtrace -l /dev/null
On Jan 14, 2008 9:22 PM, James C. McPherson [EMAIL PROTECTED] wrote:
Aubrey Li wrote:
On Jan 14, 2008 8:52 PM, Sean McGrath - Sun Microsystems Ireland
[EMAIL PROTECTED] wrote:
Aubrey Li stated:
Every first time to run dtrace command after the system boot up,
It takes a very long time
On Jan 14, 2008 9:26 PM, Aubrey Li [EMAIL PROTECTED] wrote:
On Jan 14, 2008 9:22 PM, James C. McPherson [EMAIL PROTECTED] wrote:
Aubrey Li wrote:
On Jan 14, 2008 8:52 PM, Sean McGrath - Sun Microsystems Ireland
[EMAIL PROTECTED] wrote:
Aubrey Li stated:
Every first time to run
On Jan 14, 2008 9:38 PM, James C. McPherson [EMAIL PROTECTED] wrote:
Aubrey Li wrote:
On Jan 14, 2008 9:26 PM, Aubrey Li [EMAIL PROTECTED] wrote:
On Jan 14, 2008 9:22 PM, James C. McPherson [EMAIL PROTECTED] wrote:
If you run dtrace -l with no args, *every* single loadable
module
Sorry for the delay(time difference). Now I got more details.
# truss dtrace -l
snip
mmap(0x, 4096, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFD7FFF18
mmap(0x0001, 24576, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANON|MAP_ALIGN, -1,
On Jan 15, 2008 2:45 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi Aubrey,
---snip--
setrlimit(RLIMIT_NOFILE, 0xFD7FFFDFEE80)= 0
openat(AT_FDCWD, /dev/dtrace/provider, O_RDONLY|O_NDELAY|O_LARGEFILE) = 3
fcntl(3, F_SETFD, 0x0001) = 0
fstat(3,
On Jan 15, 2008 4:43 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Aubrey Li wrote:
On Jan 15, 2008 2:45 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi Aubrey,
---snip--
setrlimit(RLIMIT_NOFILE, 0xFD7FFFDFEE80)= 0
openat(AT_FDCWD, /dev/dtrace/provider
On Jan 19, 2008 9:04 AM, Colin Burgess [EMAIL PROTECTED] wrote:
Well I see that Brendan did reply to the OSNews link to this. He basically
shot them down at hardcoding the instrumentation - as he should have! :-)
Shame on Intel - they should know better!
Colin
I'm not a member of the linux
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 behavior to
a certain extent. But
Hi list,
From the fbt driver, it's easy to understand the fbt probes are
created after fbt module
is loaded, fbt_provide_module will be called when a module is loaded and create
the fbt probes for all the functions.
But how are the fbt probes created for the modules which are loaded before fbt
11 matches
Mail list logo