On Thu, Sep 02, 2004 at 04:34:20PM -0400, Jakub Jelinek wrote: > On Thu, Sep 02, 2004 at 09:23:10PM +0100, Joe Orton wrote: > > I see the same thing here, not looked into it before though. > > > > It's interesting, if you look at the mappings of the httpd process on > > x86_64, for each mmaped object there is an extra region mapped with > > PROT_NONE, which you don't see on i686. I presume this is counted in > > the VmSize calculation - it adds up to about 100Mb of address space on > > the system I tested. > > > > e.g. > > > > 2a9b033000 12K r-xp /usr/lib64/libpanel.so.5.3 > > 2a9b036000 1012K ---p /usr/lib64/libpanel.so.5.3 > > 2a9b133000 16K rw-p /usr/lib64/libpanel.so.5.3 > > > > vs > > > > 00d57000 12K r-xp /usr/lib/libpanel.so.5.3 > > 00d5a000 4K rw-p /usr/lib/libpanel.so.5.3 > > > > is this libc behaviour by design? Jakub? > > Well, not glibc, but binutils. > The thing is, x86-64 ELF has 1MB pagesize, while i386 ELF 4KB, > so the x86-64 binaries and shared libraries must be usable even when kernel > uses 1MB pagesize. > > The gap in between RE and RW segment is there so that the library occupies > less memory (eats less 4KB pages). > > If something counts in PROT_NONE mappings into the process size, it should > be fixed. Such mappings are certainly counted in the VmSize reported by /proc/pid/status, which looks like it (mm->total_vm) is used in the OOM killer heuristics and also in the 'ps' VSZ output. I couldn't argue otherwise since it is vm space which is being "used". But if these mappings are not really consuming memory, then they are not necessarily the cause of your problems, Axel. It does mean that if you *do* run out of memory, then the httpd processes are more likely to get OOM killed on x86_64 than on i386. joe
