lkml.org 
[lkml]   [1998]   [Mar]   [20]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateFri, 20 Mar 1998 22:07:59 +0100
FromPhilipp Reisner <>
SubjectRe: mergemem utility: tests and BUGS
Marnix Coppens wrote:
> 
> I've done some hasty experiments with the mergemem patch on a 2.0.33 kernel.
[...] 
> 2) This is probably something weird about shared libraries, but I had hoped
> a lot more of their data could have been shared. Try the following:
> 
> $ dc &
> $ dc &
> $ mergemem -n dc
> ....
> comparing mapping 400a9000-400dc000 (51 pages, 204 KB)
> pid 9160: 0p merged, 1p shared, 0p errors, 50p not merged
> pid 9159: 0p merged, 1p shared, 0p errors, 50p not merged
> ....
> 
> The extract shown above belongs to the libc.so.5.4.23 inode (20451):
> 
> $ cat /proc/9159/maps
> ....
> 40008000-400a3000 r-xp 00000000 03:02 20451 --> 155 pages
> 400a3000-400a9000 rw-p 0009a000 03:02 20451 -->   6 pages
> 400a9000-400dc000 rw-p 00000000 00:00 0     -->  51 pages
> bfffe000-c0000000 rwxp fffff000 00:00 0     -->  stack
> 
> $ size /lib/libc.so.5.4.23
> text    data    bss     dec     hex     filename
> 515768  137534  207900  861202  d2412   /lib/libc.so.5.4.23
> (126p)  (34p)   (51p)
> 
> Apparently, 50 pages out of a total of 51 in the bss section (!) cannot
> be shared between the two instances of dc, who only differ in their pid.
> Can someone explain this ?
> Looks like only a dump of those particular pages will tell the difference.
> FWIW, I also noticed that the checksum operation failed a few dozen times
> with the error MERGEMEM_NOPAGE1. This is really odd.
> BTW, I've noticed that the get_phys_addr() routine being used for this
> is a straight copy from fs/proc/array.c, so that should be all right..

Since Linux does demand-paging, only a few pages of the 
mapping 400a9000-400dc000 are already present... thus the checksum
operation failing with MERGEMEM_NOPAGE1. 

> 3)[BUG] This may be related to the error above, but in certain circumstances,
> when you *keep doing* mergemem on two apps, it just keeps finding
> pages to share, although in reality there aren't anymore after the first
> time. As a nasty side effect, though, the RSS of the second instance
> keeps decreasing until it wraps and becomes really high again :).
> Luckily, this doesn't crash neither kernel nor application,
> but it sure isn't healthy.
> 
> Try this:
> 
> Create two rxvt's (or xterm) and find their pid. Leave one of them alone,
> and in the other one, start the following:
> 
> $ while true; do mergemem -p pid1 -p pid2; done
> 
> This will cause this instance of rxvt to change its contents a lot.
> The mergemem output shows it keeps on finding 376 KB to share every time.
> Running top or ps -aux tells a different tale. Notice what happens to the
> RSS of the other instance...

Hmm, the strange thing is, that this only happens to rxvts, kvts, xterms
etc...
No idea jet...

------------------------------------------------------------------------
     Want to try something new?            Are you a Linux hacker?
                    Volunteer in testing mergemem!
         (Get it from http://www.mondoshawan.ml.org/mergemem)
-----
  Philipp Reisner     E-Mail    mailto:e9525415@student.tuwien.ac.at


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 12:41    [from the cache]
©2003-2008