Runtime: mlock을 사용할 수 없을 때 CoreCLR 실행 실패

cc @tmds @alucryd

이것이 일부 타격을 주는 몇 가지 예는 https://github.com/dotnet/source-build/issues/285#issuecomment -399949984 및 https://github.com/rpm-software-management/mock/issues/186 을 참조하십시오. 빌드

mlock 는 GC에 대한 안정적인 런타임 일시 중단을 보장하는 데 중요한 FlushProcessWriteBuffers PAL 함수의 적절한 동작에 필요합니다. 이유에 대한 설명은 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/. 그 이유는 시스템 호출이 내부적으로 시스템에서 실행 중인 모든 스레드가 수십 밀리초가 걸릴 수 있는 컨텍스트 전환을 통과할 때까지 대기하기 때문입니다. 그러나 이 기사에서 언급한 좋은 소식은 Linux 4.14부터 sys_membarrier 시스템 호출에 전달할 수 있는 새로운 플래그가 있으며 이는 메모리 장벽 의미 체계를 구현하기 위해 IPI를 사용하도록 만듭니다. 그리고 그것은 훨씬 더 빠릅니다. 그래서 우리는 그것을 시도해야합니다.