Are you basically saying there is no difference in memory usage when comparing static linking and dynamic linking? Any links to more info on the matter?
I tested this on the machine with a static executable I compiled it looks to me that memory is not shared when statically linked. I thought the point of dynamic linking anyways was to save memory by sharing it (and disk space, though these days we have more than enough for executable code).
Though it could be just that I misunderstand the output of smaps_rollup.
Multiple executions of the same executable will share the code pages, so assuming all the users are executing the same binary on disk, the memory should be shared. Shared libraries only give you additional deduplication in the case that multiple binaries are loading the same shared libraries.
> Are you basically saying there is no difference in memory usage when comparing static linking and dynamic linking?
In your case, yes, there is (almost [1]) no difference at all.
If you have 500 different PHP binaries (say, different version of PHP) with same set of extension `.so`-s shared between them (is this even possible?? but let's assume it is), then your example works.
[1] Almost, because if you also linked libc statically (not recommended as glibc is specifically designed to be hostile to static linking), you can't share libc with other processes (e.g. nginx, systemd, etc) so you need ~2MB more memory, this is still paid only once, not multiplied by how many php binary you run, though.
Dynamic linking gets you two benefits: reduced size on disk (which was a bigger deal a few decades ago) and also the dynamic libraries can be updated/patched without needing to recompile the entire system (so that when openssl.so gets upgraded on disk, you just restart all the processes on the system that link it (because processes still have the old library in memory) and you're done).
This is going to sound a little weird, but if the filesystem did chunked content-aware deduplication, and if the linker knew about this and wrote out compilation units on chunk boundaries... then you could statically compile everything on the system and yet, all different binaries that have libc.a, libm.a, openssl.a etc statically linked would share the same storage and thus the same page cache.
In the example of 500 different PHP versions, if the changes were very minor (as a contrived example, a change in version.c that puts the user's username in the version string), version.c would compile to a different version.o for each user, but main.c/main.o could be identical, and then the magic dedup-aware linker mentioned above writes seven and a half disk chunks' worth of the compiled code from main.o (but those are identical to the chunks written previously, so they don't actually cause writes), one mostly-empty disk chunk for the code from version.o (which will be different than any other chunk, so you'll have 500 disk chunks each with a different version of version.o).
If the changes were more major (say, the tip of main on [0] and the 499 previous versions), there would be less sharing, but still probably quite a lot. There's also wasted space like the ends of all the version.o chunks; if a chunk is 64kB then there's probably a fair amount of wasted space and maybe the whole experiment doesn't net you anything.
Of course, under this kind of system you'd have to recompile the world when you update a core library like libc.
edit: oh man there's tons of fun stuff happening in this area already and has been for years! nix is chunking NARs as of [0] (though I haven't found anything yet about linkers being made to chunk them better for dedup ahead of time, or about re-linkers that do this with already-linked binaries, but maybe their implementation of FastCDC can do it!?). this is so cool!
Also don't forget that statically linked executables pull in less code than dynamically linked executables, so DISTINCT_EXECUTABLES_RUNNING*sizeof(libc) is very much a worst-case number rather than a typical number.
Then with static linking, the maximum memory requirement is 70MB for said extensions (statically linked into the PHP executable).