Runtime: mlockが使用できない場合、CoreCLRは実行に失敗します

作成日 2018年06月25日  ·  3コメント  ·  ソース: dotnet/runtime

CoreCLRは起動時にmlockを使用し、 mlockがEPERMで失敗すると失敗します。 一般的に、それは問題ではありません。

ただし、多くのLinuxディストリビューションは、コードの構築にsystemd-nspawnを使用し始めています。 これにより、プログラムの機能が制限されているchrootが作成されます。 具体的には、 CAP_IPC_LOCKがないため、 mlockを使用できません。

mlockが機能しない場合、coreclrは起動に失敗します。 これはstraceに次のように表示されます。

mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbd542bb000
mlock(0x7fbd542bb000, 4096)       = -1 EPERM (Operation not permitted)
write(2, "Failed to initialize CoreCLR, HR"..., 49) = 49

その結果、これにより、一部のLinuxディストリビューションビルドシステムでcoreclrをビルドすることが基本的に不可能になります。

area-PAL-coreclr os-linux
ソース
picture omajid

最も参考になるコメント

mlockは、GCの信頼性の高いランタイム一時停止を保証するために重要なFlushProcessWriteBuffersPAL関数の適切な動作に必要です。 理由の説明については、 https： //github.com/dotnet/coreclr/blob/e6ebea25bea93eb4ec07cbd5003545c4805886a8/src/pal/src/thread/process.cpp#L3095-L3098を参照して
Linux 4.3以降では、FlushProcessWriteBuffersを実装するための代替メカニズムとして使用できるsys_membarrierシステムコールがあります。 課題dotnet / runtime＃4501はそれを追跡しています。 @sdmacleaはそれを実装しようとし、ARM64でテストしました。 彼は、パフォーマンスが非常に悪く、約11000のcoreclrテストの実行時間が約50％長くなったことを発見しました。 ただし、他のハードウェアでのテストは行われていなかったため、パフォーマンスの問題がARM64固有の問題なのか、全体的な問題なのかは明確ではありませんでした。
興味深いことに、sys_membarrierのパフォーマンスの問題について説明している次の記事を発見しました： https ：//lttng.org/blog/2018/01/15/membarrier-system-call-performance-and-userspace-rcu/

picture janvorli 2018年06月26日
👍4

全てのコメント3件

cc @tmds @alucryd

omajid picture omajid 2018年06月25日

いくつかの例については、 https：//github.com/dotnet/source-build/issues/285#issuecomment-399949984およびhttps://github.com/rpm-software-management/mock/issues/186を参照してください。ビルド

omajid picture omajid 2018年06月25日

mlockは、GCの信頼性の高いランタイム一時停止を保証するために重要なFlushProcessWriteBuffersPAL関数の適切な動作に必要です。 理由の説明については、 https： //github.com/dotnet/coreclr/blob/e6ebea25bea93eb4ec07cbd5003545c4805886a8/src/pal/src/thread/process.cpp#L3095-L3098を参照して
Linux 4.3以降では、FlushProcessWriteBuffersを実装するための代替メカニズムとして使用できるsys_membarrierシステムコールがあります。 課題dotnet / runtime＃4501はそれを追跡しています。 @sdmacleaはそれを実装しようとし、ARM64でテストしました。 彼は、パフォーマンスが非常に悪く、約11000のcoreclrテストの実行時間が約50％長くなったことを発見しました。 ただし、他のハードウェアでのテストは行われていなかったため、パフォーマンスの問題がARM64固有の問題なのか、全体的な問題なのかは明確ではありませんでした。
興味深いことに、sys_membarrierのパフォーマンスの問題について説明している次の記事を発見しました： https ：//lttng.org/blog/2018/01/15/membarrier-system-call-performance-and-userspace-rcu/

janvorli picture janvorli 2018年06月26日
👍4
このページは役に立ちましたか？
0 / 5 - 0 評価

関連する問題

nalywa picture nalywa  ·  3コメント
jzabroski picture jzabroski  ·  3コメント
v0l picture v0l  ·  3コメント
iCodeWebApps picture iCodeWebApps  ·  3コメント
bencz picture bencz  ·  3コメント