This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Fwd: DTrace for Linux
- From: James Dickens <jamesd dot wi at gmail dot com>
- To: "systemtap at sources dot redhat dot com" <systemtap at sources dot redhat dot com>
- Date: Thu, 15 Dec 2005 19:58:08 -0600
- Subject: Fwd: DTrace for Linux
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FnNhBaMIEtyuyT4lUbMufwBuo2pT98a1yK+gvj4GDt/LqaAbMsNxmh51q1494YXQk5/N0O1arRS98nydTboOcF7UbeSXc4NmphmuVLFXOx0mAjK7CrUXf5dkBVz5jQMeMYbRwpS+sY+N73d3Hp7nHfr5x9PEPIdYXMb0FQZPsvI=
- References: <CBDB88BFD06F7F408399DBCF8776B3DC05DDE7E7@scsmsx403.amr.corp.intel.com> <1134603159.3951.33.camel@monkey2> <p73wti5eu8l.fsf@verdi.suse.de> <cd09bdd10512151753t2c5234e2p6e244c24460eea8b@mail.gmail.com>
okay this was blocked so i'm resending.
---------- Forwarded message ----------
From: James Dickens <jamesd.wi@gmail.com>
Date: Dec 15, 2005 7:53 PM
Subject: Re: DTrace for Linux
To: Andi Kleen <ak@suse.de>
Cc: Martin Hunt <hunt@redhat.com>, "systemtap@sources.redhat.com"
<systemtap@sources.redhat.com>
On 16 Dec 2005 01:55:06 +0100, Andi Kleen <ak@suse.de> wrote:
> Martin Hunt <hunt@redhat.com> writes:
> >
> > OK, now this is much different than what Sun got. There is certainly no
> > munmap() problem here. Without detail about Sun's emulation environment
> > and what version of linux they are running, I cannot even guess what the
> > problem is. Maybe one clue is this odd comment "[...]what I've heard my
>
> If I understand BrandZ from the link above correctly it is essentially
> running Linux user space on a Solaris kernel.
>
> When munmap is a problem for them and it isn't on native Linux
> it just means munmap is much slower on Solaris than on real Linux.
> Now that they know they can hopefully do something about this.
>
> However he makes a point that munmap flushes TLBs and scales
> with number of CPUs. So it's possible that he ran it on a bigger
> system than you and it cost more CPU time because of that.
> But I don't quite buy this argument for top because top
> is single threaded and Linux will never do remote TLB flushes
> for a single threaded process.
>
> It should only make a difference for multithreaded programs where
> multiple threads sharing the same VM run on different CPUs.
>
> Perhaps Solaris isn't that clever in avoiding TLB flushes(?) although
> it is hard to imagine this.
okay this is getting to be off topic, but since you asked, and i have
a system running brandz
Hardware:
vmware running on a 2.613 GHz system, the vhost has 384 MB allocated to it
OS: Solaris Express Community Express build patched to run Brandz bits.
Brandz is running Centos Linux that was pre-packaged on
http://www.opensolaris.org/os/community/brandz/
-bash-2.05b# uname -av
Linux linux1 2.4.21 BrandX fake linux i686 i686 i386 GNU/Linux
-bash-2.05b#
-bash-2.05b# top -v
procps version 2.0.17
-bash-2.05b#
# dtrace -n lx-syscall:::entry'/execname == "top"/{ @[probefunc] = count(); }'
dtrace: description 'lx-syscall:::entry' matched 272 probes
^C
access 8
fstat64 8
gettimeofday 8
gtime 8
llseek 8
select 8
getdents64 32
lseek 32
stat64 80
rt_sigaction 112
fcntl64 136
write 152
alarm 168
close 256
read 328
open 336
#
okay looks normal, but no munmap, maybe he was using an older version
of brandz ( linux userland environment). But lets keep going.
lx-sys.d
#!/usr/sbin/dtrace -s
lx-syscall:::entry
/execname == "top"/
{
self->ts = vtimestamp;
}
lx-syscall:::return
/self->ts/
{
@[probefunc] = sum(vtimestamp - self->ts);
self->ts = 0;
}
dtrace: script './lx-sys.d' matched 544 probes
^C
gettimeofday 32490
llseek 47045
access 94997
gtime 111993
fstat64 129067
lseek 209131
select 276210
alarm 916786
stat64 1093732
fcntl64 1143852
getdents64 1625671
rt_sigaction 2227934
write 2336432
close 2749497
read 5171047
open 5569743
#
okay normal, but now open is using the most time, this is because
for process it opens and reads data and close, if top help them open
and just read an open filehandle, it would be a lighter procces,
especailly as more and more proccesses are running.
lx-sys2.d #!/usr/sbin/dtrace -s
lx-syscall:::entry
/execname == "top"/
{
self->ts = vtimestamp;
}
lx-syscall:::return
/self->ts/
{
@[probefunc] = sum(vtimestamp - self->ts);
@["- all syscalls -"] = sum(vtimestamp - self->ts);
self->ts = 0;
}
sched:::on-cpu
/execname == "top"/
{
self->on = timestamp;
}
sched:::off-cpu
/self->on/
{
@["- total -"] = sum(timestamp - self->on);
self->on = 0;
}
dtrace: script './lx-sys2.d' matched 550 probes
^C
getegid 16240
geteuid 20344
getgid 24503
getuid 38199
gettimeofday 49445
rt_sigprocmask 54397
llseek 57766
gtime 83750
newuname 115006
brk 126012
set_thread_area 137075
nanosleep 200987
access 253384
lseek 280470
mmap2 284076
munmap 441192
select 544337
fstat64 595619
old_mmap 595924
alarm 891482
ioctl 1060726
stat64 1602166
fcntl64 1958110
rt_sigaction 2526971
getdents64 2752676
write 3573395
socketcall 4072963
close 4954184
open 7627755
read 8364549
- all syscalls - 43303703
- total - 56738308
#
okay the rest don't apply since either he had a wierd version of top
or some other bug that has since been fixed. Maybe a race because he
has a SMP machine and I don't.
James Dickens
uadmin.blogspot.com
> -Andi
>