Setup
-----
Linux 2.2.1-ac5
Glibc 2.1
egcs-1.1.1
binutils-2.9.1.0.19a
When one of our developers attempts to build on this platform after a
fresh reboot, a free command shows ...
[steelhead] [/home/gwhalin] > free
total used free shared buffers cached
Mem: 257976 11544 246432 7348 1516 6512
-/+ buffers/cache: 3516 254460
Swap: 128484 0 128484
[steelhead] [/home/gwhalin] >
and after building, free shows ...
[steelhead] [/home/gwhalin] > free
total used free shared buffers cached
Mem: 257976 229472 28504 7752 100368 111396
-/+ buffers/cache: 17708 240268
Swap: 128484 0 128484
[steelhead] [/home/gwhalin] >
Now, I see that most of the available free memory is used up in buffers.
This normally should not be a problem, but this is the letter from the
developer that got us looking.
<cut>
Porting our code on Linux / egcs 1.1.1, I have faced with the following
problem. Few object files generated by the compiler abnormally influence
on work of utilities (nm, objdump, etc.) responsible for understanding
object files format. The utilities taking the files report either 'File
truncated' or 'Memory exhausted'. This prevents linking.
I have investigated source for binutilities and came to a conclusion
that the files can be indeed truncated as a result of compiler's work.
This can happen during compilation because of a lack of memory on the
steelhead and/or code blow caused by *.cpp files. In order to check
the hypothesis I split each file on two files containing approximately
the same amount of code (file.cpp -> file_1.cpp, file_2.cpp,
etc.). This indeed considerably improved the picture. The majority
of files were normally treated.
We have to increase memory on steelhead. If this does not help but we
need Linux/egcs 1.1.1, then we can apply files splitting approach &
conditions found (this would require to increase number of *.cpp files).
</cut>
And, a followup letter from the same developer ...
<cut>
I obtained the following data using 'top' and making snapshots of
memory conditions at different moments. Here is a brief summary (
a complete output is saved and available).
1. After rebooting steelhead.
Mem: 257972K av, 11320K used, 246652K free, 7856K shrd, 1500K buff
2. Starting build (no compilation yet).
Mem: 257972K av, 14552K used, 243420K free, 9440K shrd, 1544K buff
3. Coping of files is almost finished.
Mem: 257972K av, 39456K used, 218516K free, 9436K shrd, 1544K buff
4. Compilation (make, c++) has started.
Mem: 257972K av, 60728K used, 197244K free, 11884K shrd, 6132K buff
6. ~165 files are compiled.
Mem: 257972K av, 139868K used, 118104K free, 11460K shrd, 73288K buff
7. ~230 files are compiled.
Mem: 257972K av, 169592K used, 88380K free, 11448K shrd, 106200K buff
8. ~275 files are compiled.
Mem: 257972K av, 198680K used, 59292K free, 11404K shrd, 132508K buff
9. ~350 files are compiled.
Mem: 257972K av, 248184K used, 9788K free, 11468K shrd, 172396K buff
10. ~390 files are compiled.
Mem: 257972K av, 254924K used, 3048K free, 11884K shrd, 168996K buff
11. ~424 files are compiled. Compilation finished.
Mem: 257972K av, 250132K used, 7840K free, 8956K shrd, 169788K buff
Mem: 257972K av, 253752K used, 4220K free, 8992K shrd, 166716K buff
Mem: 257972K av, 254920K used, 3052K free, 8984K shrd, 162748K buff
Mem: 257972K av, 255180K used, 2792K free, 8984K shrd, 160060K buff
Mem: 257972K av, 254964K used, 3008K free, 8972K shrd, 153280K buff
12. Assembling libassemble.a
Mem: 257972K av, 250512K used, 7460K free, 9456K shrd, 152648K buff
Mem: 257972K av, 255248K used, 2724K free, 9604K shrd, 134856K buff
13. Appending.
Mem: 257972K av, 247452K used, 10520K free, 8968K shrd, 132808K buff
Mem: 257972K av, 251764K used, 6208K free, 8972K shrd, 132808K buff
Mem: 257972K av, 254912K used, 3060K free, 9624K shrd, 124888K buff
14. lib.a stage and when build is done.
Mem: 257972K av, 238700K used, 19272K free, 8856K shrd, 114264K buff
Mem: 257972K av, 229672K used, 28300K free, 7868K shrd, 101592K buff
15. Starting anothe shell (no much influence).
Mem: 257972K av, 230424K used, 27548K free, 10080K shrd, 101616K buff
16. After killing the first shell.
Mem: 257972K av, 229704K used, 28268K free, 7864K shrd, 101616K buff
17. After complete logoff and new loging.
Mem: 257972K av, 229588K used, 28384K free, 7868K shrd, 101616K buff
As we see the memory used by a new shell is not recovered. I also
changed the order of compilation and compiled critical files at the
beginning under a more favorable memory conditions. The number of
'bad' files reported is reduced to 4 (from 7) without any splitting
but not eliminated. Looks like we have a problem with Linux itself
(kernel or desynchronization between leaking 'make' & kernel as it was
assumed by another developer). Is it possible that this can relate to NFS
suspects discussed before? The memory is returned back after system
reboot.
</cut>
Any thoughts?
Thanks,
Greg
--------------------
Greg Whalin
gwhalin@numerix.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/