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 基本上是不可能的。
omajid
所有3条评论
抄送@tmds @alucryd
omajid
于 2018-06-25
请参阅https://github.com/dotnet/source-build/issues/285#issuecomment -399949984 和https://github.com/rpm-software-management/mock/issues/186了解一些示例构建
omajid
于 2018-06-25
mlock对于 FlushProcessWriteBuffers PAL 函数的正确行为是必要的，这对于确保 GC 的可靠运行时挂起至关重要。 有关原因的描述，请参见https://github.com/dotnet/coreclr/blob/e6ebea25bea93eb4ec07cbd5003545c4805886a8/src/pal/src/thread/process.cpp#L3095 -L3098。
在 Linux 4.3 和更高版本上，有一个sys_membarrier系统调用，我们可以使用它作为实现 FlushProcessWriteBuffers 的替代机制。 问题 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 来实现内存屏障语义。 这要快得多。 所以我们应该试一试。
janvorli
于 2018-06-26
相关问题
jamesqo
·
3评论
chunseoklee
·
3评论
matty-hall
·
3评论
v0l
·
3评论
aggieben
·
3评论
最有用的评论
mlock对于 FlushProcessWriteBuffers PAL 函数的正确行为是必要的，这对于确保 GC 的可靠运行时挂起至关重要。 有关原因的描述，请参见https://github.com/dotnet/coreclr/blob/e6ebea25bea93eb4ec07cbd5003545c4805886a8/src/pal/src/thread/process.cpp#L3095 -L3098。在 Linux 4.3 和更高版本上，有一个
sys_membarrier系统调用，我们可以使用它作为实现 FlushProcessWriteBuffers 的替代机制。 问题 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 来实现内存屏障语义。 这要快得多。 所以我们应该试一试。