[vox-tech] Need X Windows performance monitoring help

[Eric Nelson]

On Friday 16 August 2002 00:32, Peter Jay Salzman wrote:
> begin Eric Nelson <en77@attbi.com>
=2E....
> >
> > meminfo and ps have good data, but you would like to see what
> > they say, each, say 10 milliseconds.
>
> 10 ms would be the lowest granularity you'll get.  the linux kernel
> programs the internal clock to issue a timer interrupt every 10
> miliseconds.
>
> i don't know if that's x86 specific or just linux in general.  i
> suspect it's general.  that means the kernel can't keep time more
> accurate than 10 ms.
>

Well, maybe 50 ms.  What might be somewhat instructive is to write a=20
script that sleeps 50ms, then prints out pertinant /proc/=20
information, so you get snapshots.

> > I read somewhere that maybe the libraries swap out.  How can I
> > tell?
>
> no, i don't think this is right.  i mean, why bother?  a copy of
> the library is already on disk.  it doesn't make sense to swap out
> something that's already on disk.  look at a typical
> /proc/<pid>/map file:
>
> p@satan% cat 326/maps
> 08048000-08077000 r-xp 00000000 03:05 258566   /usr/X11R6/bin/xterm
> 08077000-0807f000 rw-p 0002e000 03:05 258566   /usr/X11R6/bin/xterm
> 0807f000-080dd000 rwxp 00000000 00:00 0
> 40000000-40013000 r-xp 00000000 03:05 225817   /lib/ld-2.2.5.so
> 40013000-40014000 rw-p 00013000 03:05 225817   /lib/ld-2.2.5.so
> 40015000-40017000 r-xp 00000000 03:05 1548   =20
> /usr/lib/gconv/ISO8859-1.so 40017000-40018000 rw-p 00001000 03:05
> 1548     /usr/lib/gconv/ISO8859-1.so 40023000-40038000 r-xp
> 00000000 03:05 81876    /usr/X11R6/lib/libXft.so.1.1
> 40038000-4003a000 rw-p 00014000 03:05 81876  =20
> /usr/X11R6/lib/libXft.so.1.1
>
> this field                       ^
>
> shows the location of the shared library on disk.  major number 3
> (hda), minor number 5 (partition 5).
>
> swapping only makes sense for things like stacks and heaps.  data
> that you can write to.
>
> however, each shared library is loaded into 2 maps: one which is
> executable, and one which is writable.  i don't know why that is.=20
> but maybe you're right.  maybe the writable portion copy does get
> swapped. i dunno.   if you find out, i'd like to know.
>
> by the way, doesn't the "sticky bit" of a file ensure that the file
> stays in core?  i thought that was the whole point of why hackers
> try to get a copy of a root shell with the sticky bit set.
>

OK, that all makes sense, and you've told me many things I didn't=20
know, so thanks :)

But, if you have enough ram, won't libraries move into ram, so access=20
will be faster?

=2E...
>
> pete