http://bugzilla.spamassassin.org/show_bug.cgi?id=3839
------- Additional Comments From [EMAIL PROTECTED] 2004-10-04 13:28 -------
sigh...
The more I look into this, the less and less it appears to be an issue.
This script:
#!/usr/bin/perl
# original at http://www.fedoraforum.org/forum/showthread.php?t=5336
use strict;
my $a = "\x00" x (32*1024*1024); #32Mb of data
print "[$$] forking to test perl mem sharing...\n";
if ( fork == 0 ) {
print "[$$] subprocess sleeping\n"; sleep 1;
print "[$$] subprocess done\n"; exit;
}
print "[$$] reporting\n";
my @statm = split(m/\s+/,`cat /proc/$$/statm`);
my $statmstr = join(' ', @statm);
my $ratio = ($statm[2]/$statm[1]);
my $uname = `uname -sr`; chomp $uname;
print "ratio: ".int($ratio*100)."\% uname: $uname statm: $statmstr\n";
wait; print "[$$] done\n";
allocates a large 32-meg string, forks, and outputs the Linux kernel
per-process stats that "top" bases its info on (from /proc/$$/statm). Since the
large string has not been modified (or even accessed) since the fork, a large
portion of those pages should be shared if copy-on-write is doing anything
at all. ;)
In fact, the results are:
- Linux 2.4.[12]*, vanilla kernels: 99% shared
- Linux 2.4.[12]*, Red Hat kernels: 1-3% shared
- Linux 2.6.*, vanilla kernels: 1-3% shared
Looking into the latter, it appears that yes, 2.6.x changed the data reported
from /proc/$$/statm so that it just reports (text + shared-lib-code) for the
"shared" field, not what quite a few people (myself included ;) thought it
means. I'll bet the RH kernels are the same.
Anyway, I've found a machine where the results are reliable (reports 99%
from that script) so will test there.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
