l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2002 Aug 17 10:37

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

> > 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 :)

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

> pete

vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
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:
Sunset Systems
Who graciously hosts our website & mailing lists!