3

Linux ベースのビルド システムがあり、ビルドはさまざまな組み込みターゲット (対応するさまざまなドライバーと機能セットが有効になっている) で構成され、それぞれが別の単一のメイン ソース ツリーでビルドされます。

make ベースのシステムをよりマルチプロセスに適したものに変換しようとするのではなく、これらすべてのターゲットのビルドを同時に起動する最善の方法を見つけたいだけです。よくわからないのは、最高のパフォーマンスを得る方法です。

次の可能な解決策を検討しました。

  • 多数の個別のビルド マシン。欠点: 共有コードのコピーがたくさんある、または (遅い) 共有ドライブから作業している。維持するシステムが増えます。
  • 高速ストライプ RAID ローカル ストレージを備えた少数のマルチプロセッサ マシン (おそらくデュアル クアッドコア)。欠点: どのようにスケーリングするかはわかりません。ボリュームがボトルネックになりそうですが、最近の Linux が SMP をどれだけうまく処理できるかはわかりません。
  • 類似の SMP マシンですが、VMware を実行するハイパーバイザーまたは Solaris 10 を備えています。これはばかげているでしょうか、それともスケジューリングの利点を提供しますか? 欠点: ストレージのボトルネックの問題に対処していません。

座ってこれらの可能性を試すつもりですが、見落としがないかどうかを確認したかったのです。ありがとう！

4

3 に答える 3

1

ソフトウェア ソリューションに関する限り、Icecreamをお勧めします。これは SUSE によって維持され、distcc 上に構築されます。

あなたが説明したものと同様のビルド要件を持っていた私の前の会社で、私たちはそれを非常にうまく使用しました.

于 2009-06-16T20:53:38.600 に答える
0

高速なインクリメンタル パフォーマンスに関心がある場合は、再構築が必要なファイルを計算するコストが実際のコンパイル時間よりも大きくなり、マシン間の効率的な I/O に対する要求が高くなります。

ただし、高速で完全なリビルド (夜間のビルドなど) に主に関心がある場合は、ソース ツリーを各ビルド スレーブに再同期するか、各ビルド スレーブにソース管理から独自のコピーをチェックアウトさせる方がよい場合があります。 . Hudson などの CI システムは、各スレーブ ビルド サーバーの管理に役立ちます。

于 2009-06-12T20:56:13.600 に答える
0

-jビルド マシンに十分なメモリがある場合、makefile が十分に完全で適切に構造化されていて、I/O のボトルネックを克服するのにフラグが役立つ場合もあります。これにより、make は複数の独立したタスクを並行して実行できるため、理想的には CPU が I/O の待機をブロックすることはありません。一般に、マシンに搭載されている CPU よりも多くのタスクを許可することで、良い結果が得られました。

現在のメイクファイルがこれに対応していないのか、それともメイクとはまったく異なるものにジャンプしたくないだけなのか、あなたの質問からは明らかではありません。

于 2009-06-17T04:35:11.963 に答える