On 22/08/2019 17:34, Brüns, Stefan wrote:
On Donnerstag, 22. August 2019 15:13:27 CEST Dave Plater wrote:
Somebody used this macro in my graphics/blender package as a replacement for a conditional that I had to decrease the number of build threads. They used -m 800 which appeared to work but intermittent failures due to oom are hard to trouble shoot. The person that had been testing blender git prior to the update to blender 2.80 informed me that there were intermittent oom build failures so I reduced -m to 600 but it's failing more now. I've increased it to 2G -m 2000 because it appears to me that requesting 2G per thread should result in less threads but I wonder why the original user made such a small value in the beginning? Am I right to assume that the higher the -m value the less resulting build threads and the less consumed memory?
The macro works as 'how much memory you need for one core' so having -m 800 means it will be 800MB per core. If you use 2000 it will be 2GB per core and thus limit the threading even more.
Thanks, that's what the wiki implies. Thanks to Jan for the formula, I'll put it in the wiki. I think the experienced packager who put the macro in the spec file was confused.
At the time the limit was added, the value was totally appropriate, and the package built successfully several hundreds of times in the graphics project and in Factory.
There are several possible reasons why the built started to fail, e.g. the compiler has been updated several times, LTO has been enabled by default, also the libraries used have been updated. All this can cause a slight or even a significant increase of required memory.
The fact the build occasionaly succeeded suggests the assumed average of 800 MByte per thread is not too far off, so a sufficient value appropriately is 900 or 1000 MByte per thread. Reducing it to 600 MByte of course is a change in the wrong direction.
Regards,
Stefan
I've seen an lto= value greater than the resulting thread number in one failed build so far which means that there is a bug somewhere. It's building atm but I'll watch what happens. I can't understand the lto value being greater than the jobs number AFAIK it gets it's value from the resulting jobs value but I may be wrong. Regards Dave -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org