[vox-tech] Need X Windows performance monitoring help

[Eric Nelson]

On Saturday 17 August 2002 10:36, Peter Jay Salzman wrote:
> 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.=20
> > > 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".    :-)
>

well, yes, and maybe I should try 2.5.x, heh, heh.  no, I'm not ready=20
to go that deep.=20

> > > > 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 =20
> > > /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.=20
> > > 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?
>

I read that some people 'lock X into memory', so I guess that must be=20
what they mean.

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

Does that mean they are in ram?  Wouldn't that still be a question of=20
how much ram is available?  They will work on disk, they will just=20
work faster in ram.

> 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

my problem is that this project is at work, and I use this list on=20
evenings and weekends, and, at this point, another guy is doing=20
actual benchmarking, so there is often a big delay between you guys=20
saying something, and the time I can check it out.  Hence, big lags. =20
But, I will try to use the things you guys have said to see if ram is=20
the issue.

But, typically, it seems like, if you have 128 meg of ram, the kernel=20
uses most of that; you change the same system to 256 meg, and the=20
kernel uses most of that.  It makes sense, use what u've got. =20