Hugh Dickins wrote:

On Sat, 21 Sep 2002, Andrew Morton wrote:

quoted

Hugh Dickins wrote:

quoted

...

quoted

It seems very unlikely (impossible?) that those pages will
ever become unshared.

I expect it's very unlikely (short of application bugs) that
those pages would become unshared; but they have been mapped
in such a way that the process is entitled to unshare them,
therefore they have been counted.  A good example of why
Linux does not impose strict commit accounting, and why
you may choose not to use Alan's strict accounting policy.

OK, thanks.   Just checking.

Is glibc mapping executables with PROT_WRITE?  If so,
doesn't that rather devalue the whole overcommit thing?

No, it looks like glibc is doing the right thing (mapping the code
readonly and the data+bss readwrite).  And I was wrong to say it's
unlikely those pages would ever become unshared: the four 0.5MB
areas look like typical readwrite private anon allocations.

hm.  That would be two megs of real memory per task?  So maybe
I wasn't running 10000 tasks.  It's hard to say - running ps
with that many processes in the machine appears to take longer
than I have left on this earth.

Maybe an `ls /proc | wc' would tell me.  Dunno; I've moved onto
other bugs for today.  Bill seems to be into this stuff.  Hopefully
he'll retest on the next -mm, which should be a bit nicer to
those-who-run-too-many-tiobenches.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/