Runtime: فشل CoreCLR في العمل عند عدم توفر mlock
يستخدم 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
نتيجة لذلك ، هذا يجعل من المستحيل أساسًا بناء coreclr في بعض أنظمة إنشاء توزيع Linux.
omajid
ال 3 كومينتر
تضمين التغريدة
omajid
في ٢٥ يونيو ٢٠١٨
راجع https://github.com/dotnet/source-build/issues/285#issuecomment -399949984 و https://github.com/rpm-software-management/mock/issues/186 للحصول على بعض الأمثلة حيث يضرب هذا البعض يبني
omajid
في ٢٥ يونيو ٢٠١٨
يعد mlock ضروريًا للسلوك الصحيح لوظيفة FlushProcessWriteBuffers PAL التي تعد ضرورية لضمان تعليق وقت تشغيل موثوق به لـ GC. راجع https://github.com/dotnet/coreclr/blob/e6ebea25bea93eb4ec07cbd5003545c4805886a8/src/pal/src/thread/process.cpp#L3095 -L3098 للحصول على وصف السبب.
في Linux 4.3 والإصدارات الأحدث ، يوجد sys_membarrier syscall يمكننا استخدامه كآلية بديلة لتطبيق FlushProcessWriteBuffers. المشكلة dotnet / runtime # 4501 هو تتبع ذلك. حاولت sdmaclea تنفيذها واختبرتها على ARM64. لقد وجد أن الأداء كان سيئًا حقًا وأن وقت تشغيل اختباراتنا ~ 11000 كوريكلر كان أطول بحوالي 50٪. ومع ذلك ، لم يتم إجراء أي اختبار على أجهزة أخرى ، لذلك لم يكن من الواضح ما إذا كانت مشكلة الأداء خاصة بـ ARM64 أو مشكلة عامة.
ومن المثير للاهتمام ، أنني اكتشفت للتو المقالة التالية التي تصف مشكلات الأداء مع sys_membarrier: https://lttng.org/blog/2018/01/15/membarrier-system-call-performance-and-userspace-rcu/. والسبب هو أن syscall ينتظر داخليًا حتى تمر جميع مؤشرات الترابط قيد التشغيل على النظام من خلال تبديل السياق ، والذي قد يستغرق عشرات من المللي ثانية. لكن الخبر السار المذكور في هذه المقالة هو أنه بدءًا من Linux 4.14 ، هناك علامة جديدة يمكن تمريرها إلى sys_membarrier syscall والتي تجعلها تستخدم IPI لتنفيذ دلالات حاجز الذاكرة. وهذا أسرع بكثير. لذلك يجب أن نجربها.
janvorli
في ٢٦ يونيو ٢٠١٨
القضايا ذات الصلة
omariom
·
3تعليقات
Timovzl
·
3تعليقات
bencz
·
3تعليقات
ilmax
·
3تعليقات
sahithreddyk
·
3تعليقات
التعليق الأكثر فائدة
يعد
mlockضروريًا للسلوك الصحيح لوظيفة FlushProcessWriteBuffers PAL التي تعد ضرورية لضمان تعليق وقت تشغيل موثوق به لـ GC. راجع https://github.com/dotnet/coreclr/blob/e6ebea25bea93eb4ec07cbd5003545c4805886a8/src/pal/src/thread/process.cpp#L3095 -L3098 للحصول على وصف السبب.في Linux 4.3 والإصدارات الأحدث ، يوجد
sys_membarriersyscall يمكننا استخدامه كآلية بديلة لتطبيق FlushProcessWriteBuffers. المشكلة dotnet / runtime # 4501 هو تتبع ذلك. حاولت sdmaclea تنفيذها واختبرتها على ARM64. لقد وجد أن الأداء كان سيئًا حقًا وأن وقت تشغيل اختباراتنا ~ 11000 كوريكلر كان أطول بحوالي 50٪. ومع ذلك ، لم يتم إجراء أي اختبار على أجهزة أخرى ، لذلك لم يكن من الواضح ما إذا كانت مشكلة الأداء خاصة بـ ARM64 أو مشكلة عامة.ومن المثير للاهتمام ، أنني اكتشفت للتو المقالة التالية التي تصف مشكلات الأداء مع sys_membarrier: https://lttng.org/blog/2018/01/15/membarrier-system-call-performance-and-userspace-rcu/. والسبب هو أن syscall ينتظر داخليًا حتى تمر جميع مؤشرات الترابط قيد التشغيل على النظام من خلال تبديل السياق ، والذي قد يستغرق عشرات من المللي ثانية. لكن الخبر السار المذكور في هذه المقالة هو أنه بدءًا من Linux 4.14 ، هناك علامة جديدة يمكن تمريرها إلى sys_membarrier syscall والتي تجعلها تستخدم IPI لتنفيذ دلالات حاجز الذاكرة. وهذا أسرع بكثير. لذلك يجب أن نجربها.