[vox-tech] Need X Windows performance monitoring help

[Peter Jay Salzman]

begin Eric Nelson <en77@attbi.com> 
> On Friday 16 August 2002 00:32, Peter Jay Salzman wrote:
> > begin Eric Nelson <en77@attbi.com>
> .....
> > >
> > > 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 
> script that sleeps 50ms, then prints out pertinant /proc/ 
> information, so you get snapshots.
 
ok, i was a little wrong here.  i went through the kernel source, and
i'll try to be more accurate.

we all know that every computer has an internal clock.  the clock is
tied directly to the CPU via an interrupt and is programmable in the
sense that the kernel can tell the clock to generate an IRQ at some
specified interval.

think of it as an alarm clock that tells the kernel when a time delta t 
has passed, where the kernel can specify what delta t is.

look in /usr/src/linux/include.  in addition to other things, there
should be a symlink directory "asm" along with other asm directories
like "asm-ia64".  these asm directories are include files for assembler
routines which are, of course, processor specific.  for instance, my asm
symlink points to asm-i386.

now look in /usr/src/linux/include/asm/param.h:

#ifndef HZ
#define HZ 100
#endif

so for the i386 platform, the HZ variable is 100 (i previously said it
was 10).  i think this means that the clock beeps an IRQ 100 times per
second (every .01 seconds).   this is the granularity of time in the
linux kernel.

btw, there's another kernel variable named "unsigned long jiffies" which
gets incremented each time the clock beeps an IRQ.  this variable is
used to keep track of time (rather than intervals of time) in the
kernel.  it will overflow at some point (just when is dependent on the
architecture), but the shortest overflow interval is over a year.
nothing special happens when it does.  i'm more familiar with modules
than i am with the kernel, but i'm sure alot of effort has gone into
making sure nothing bad happens when jiffies overflows.

btw, in /usr/src/linux/timex.h:

/*
 * The following defines establish the engineering parameters of the PLL
 * model. The HZ variable establishes the timer interrupt frequency, 100 Hz
 * for the SunOS kernel, 256 Hz for the Ultrix kernel and 1024 Hz for the
 * OSF/1 kernel. The SHIFT_HZ define expresses the same value as the
 * nearest power of two in order to avoid hardware multiply
 * operations.
 */

now why mention any of this?  embedded linux (and some gamers, because
embedded programmers and gamers have so much in common) raises the value
of HZ.  all you need to do is change the value in
/usr/src/linux/asm/param.h.   they do this to get better response time
from the kernel.  realize that there's a tradeoff.  smaller time
granularity means using time more efficiently, but it also means more
overhead per second because of more interrupt service requests.  linus
has determined that 100 HZ is the optimal delta t for the standard i386
PC.  this, of course, can't be optimal for EVERYONE.  but a choice had
to be made.  you can't dynamically change this variable because alot
depends on it.

i typed all that just to say "maybe you can play with HZ".    :-)


> > > 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    
> > /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   
> > /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. 
> > 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 
> know, so thanks :)
 
heh.  it's a fun thread and is covering alot of stuff i consider "my
hobby".   :-)

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

i'm not convinced that's your bottleneck.  i was hoping someone would
comment on my "sticky bit" idea.   anyone?

libraries get mmap()'ed.  access to shared code should be the same thing
as access to memory.

i don't think the kernel makes it a habit of moving data out of RAM for
no good reason.  why don't you look at memory usage and see if you're
even *close* to maxing out physical RAM?   if you're not even close, i
don't think this is the avenue you want to purse.

pete

-- 
GPG Fingerprint: B9F1 6CF3 47C4 7CD8 D33E  70A9 A3B9 1945 67EA 951D