From: James Dickens <jamesd.wi@gmail.com>
To: "systemtap@sources.redhat.com" <systemtap@sources.redhat.com>
Subject: Fwd: DTrace for Linux
Date: Fri, 16 Dec 2005 02:24:00 -0000 [thread overview]
Message-ID: <cd09bdd10512151758uc95044dnf75217f45f0e1d40@mail.gmail.com> (raw)
In-Reply-To: <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
>
next prev parent reply other threads:[~2005-12-16 1:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-14 21:49 Stone, Joshua I
2005-12-14 23:51 ` Martin Hunt
2005-12-15 1:55 ` Kevin Stafford
2005-12-16 1:05 ` Andi Kleen
[not found] ` <cd09bdd10512151753t2c5234e2p6e244c24460eea8b@mail.gmail.com>
2005-12-16 2:24 ` James Dickens [this message]
2005-12-16 3:02 ` Andi Kleen
2005-12-16 5:02 ` weikong
2005-12-16 7:55 ` Martin Hunt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cd09bdd10512151758uc95044dnf75217f45f0e1d40@mail.gmail.com \
--to=jamesd.wi@gmail.com \
--cc=systemtap@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).