Birden çok çekirdeği derlerken markanın askıda kalmasına ne sebep olabilir?

Dün ROOT paketini kaynaktan derlemeye çalışıyordum . 6 çekirdekli bir canavar makinesinde derlediğim için, devam edip çoklu çekirdekler kullanarak inşa etmeye karar verdim make -j 6. Derleme ilk başta düzgün ve hızlı oldu, ancak bir noktada make% 100 CPU kullanarak tek bir çekirdeğe asıldı.

Bazı googling yaptım ve bu gönderiyi KÖK mesaj panolarında buldum . Bu bilgisayarı kendim kurduğumdan beri, soğutucuyu düzgün bir şekilde uygulamadığımdan ve CPU'nun aşırı ısınmasından falan endişeliydim. Ne yazık ki, işte burada yapıştırabileceğim bir buzdolabı yok. ;-)

lm-sensorsPaketi kurdum ve make -j 6tekrar çalıştırdım , bu sefer CPU sıcaklığını izledim . Yüksek olmasına rağmen (60 C'ye yakın), asla yüksek veya kritik sıcaklığı geçmedi.

Koşmayı denedim make -j 4ama makederleme sırasında bir kez daha asıldım, bu sefer farklı bir noktada.

Sonunda, sadece koşarak derledim makeve iyi çalıştı. Sorum şu: Neden asılıydı? İki farklı noktada durması nedeniyle, bir çeşit yarış durumundan kaynaklandığını tahmin ediyorum, ancak seçeneği makesunduğu için her şeyi doğru sırayla alacak kadar zeki olmalı -j.

Bu kesin konuya bir cevabım yok, ama size neler olabileceğine dair bir ipucu vermeye çalışabilirim: Makefiles'deki eksik bağımlılıklar.

Misal:

target: a.bytecode b.bytecode
    link a.bytecode b.bytecode -o target

a.bytecode: a.source
    compile a.source -o a.bytecode

b.bytecode: b.source
    compile b.source a.bytecode -o a.bytecode

Aradığınızda make targether şey doğru derlenir. Derlemesi önce a.source(keyfi fakat belirleyici olarak) yapılır. Sonra derlemesi b.sourceyapılır.

Ancak make -j2 targether iki compilekomut da paralel olarak çalıştırılacaktır. Ve aslında Makefile'nizin bağımlılıklarının bozulduğunu fark edeceksiniz. İkinci derleme varsayımlarının a.bytecodederlenmiş olduğunu, ancak bağımlılıklarda görünmediğini varsayar . Yani bir hata olması muhtemeldir. İçin doğru bağımlılık hattı şöyle b.bytecodeolmalıdır:

b.bytecode: b.source a.bytecode

Sorununuza geri dönmek için, şanslı değilseniz, bir bağımlılığın eksik bir bağımlılık nedeniyle% 100 CPU döngüsünde asılı kalması mümkündür. Muhtemelen burada olan şey budur, eksik bağımlılık sıralı bir yapı tarafından açığa çıkarılamaz, ancak paralel yapınız tarafından ortaya çıkarılmıştır.

Makineye ne kadar zamandır sahip olduğumu bilmiyorum, ancak ilk önerim bir bellek testi denemek ve belleğin düzgün çalıştığını doğrulamak olacaktır. Sıklıkla sorunun hafızası olmadığını biliyorum, ama eğer öyleyse, diğer olası sorunları izlemeye çalışmadan önce bir neden olarak ortadan kaldırmak en iyisidir.

Bunun gerçekten eski bir soru olduğunu anlıyorum, ancak yine de arama sonuçlarının en üstünde ortaya çıkıyor, işte benim çözümüm:

GNU markası, markayı sağlamak için bir işveren mekanizmasına sahiptir ve özyinelemeli çocukları belirtilen sayıda çekirdekten fazla tüketmemelidir: http://make.mad-scientist.net/papers/jobserver-implementation/

Tüm süreçler tarafından paylaşılan bir boruya dayanır. İlave çocukları çatallamak isteyen her işlem önce borudan jeton tüketmeli, sonra bittiğinde onları bırakmalıdır. Bir alt süreç tüketilen jetonları döndürmezse, üst düzey sonsuza dek geri dönmelerini beklerken bekler.

https://bugzilla.redhat.com/show_bug.cgi?id=654822

Solaru kutumda GNU ile binutils oluştururken "sed" in GNU sed olmadığı halde bu hatayla karşılaştım. Sed == gsed yapmak için PATH ile uğraşmak, sistem sed'e öncelik vermek sorunu düzeltti. Gerçi neden borudan jeton tüketiyor bilmiyorum.

sisteminiz iyi olabilir, ancak makeparalel sürümler oluştururken meydana gelen bir yarış durumu olabilir .

Sisteminizle ilgili bir sorun varsa, yalnızca paralel derlemeler yaparken değil, diğer senaryolar için de kilitlenir.

Bu bir yarış koşulu olabilir, ancak gerekli tüm derleme paralel olarak yapılır ve başkalarını beklerse, bağlantı yapmak makinenizde zamanınızı alır. Bağlamanın paralel olarak önceki gerekli derlemeyi beklemesi durumunda, derlediğiniz her şeyi bağlarken yüksek cpu frekansı elde edersiniz.