FAQ

You are right in this case: the pages would be shared just after the fork, but would
probably start to get copied individually for each process again as soon as the process
starts doing something useful. For perl, which works as some kind of JIT compiler, the
script executable code is just data and probably gets rewritten very often, so each
process would end with its own set of pages.

I'd bet for a KSM capable machine and OS. You can activate and deactivate it, so
benchmarking it with your app would be trivial.
I would suppose that loading all the modules needed would generate the internal perl
representation, and that won't change during execution. It doesn't get rewritten unless
it's unloaded, which doesn't happen to named package contents.

It's plausible that multiple fire-ups of the same program would wind up with identical
pages, if no memory allocation ever depends on timing or anything other than static
configuration.

In Windows, the executable code of a process is "backed" by the exe file and shares
physical pages with every process that loaded it. Paging out just forgets it, and paging
it reads it from the exe file again. Would you know if Linux, with its fork/exec model,
does likewise?

Of course, I know that doesn't help the Perl code, which is data as far as the Kernel is
concerned.

FWIW, VMWare does its own KSM at a higher level, across virtual machines. So if that is
possible it does reduce the real load on the host hardware. But it doesn't change how I'm
billed!

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 6 of 9 | next ›
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedApr 11, '11 at 1:07p
activeApr 29, '11 at 2:11p
posts9
users3
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase