l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
April 21: Google Glass
Next Installfest:
TBD
Latest News:
Mar. 18: Google Glass at LUGOD's April meeting
Page last updated:
2002 Aug 17 12:51

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Need X Windows performance monitoring help
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Need X Windows performance monitoring help



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. 
> > > 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 
to go that deep. 

> > > > 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?
>

I read that some people 'lock X into memory', so I guess that must be 
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 
how much ram is available?  They will work on disk, they will just 
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 
evenings and weekends, and, at this point, another guy is doing 
actual benchmarking, so there is often a big delay between you guys 
saying something, and the time I can check it out.  Hence, big lags.  
But, I will try to use the things you guys have said to see if ram is 
the issue.

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

_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.