CPU affinity โต้ตอบกับ cgroups ใน Linux อย่างไร


10

ฉันพยายามเรียกใช้การวัดแบบหลายเธรดในชุดของซีพียูแบบแยกตัว ตัดเรื่องยาวสั้นผมเริ่มพยายามกับisolcpusและtasksetแต่ตีปัญหา ตอนนี้ฉันกำลังเล่นกับ cgroups / csets

ฉันคิดว่ากรณีการใช้ "แบบง่าย" cset shieldควรใช้งานได้ดี ฉันมี 4 คอร์ดังนั้นฉันจึงต้องการใช้คอร์ 1-3 สำหรับการเปรียบเทียบ (ฉันได้กำหนดค่าแกนเหล่านี้ให้อยู่ในโหมดติ๊กปรับตัว) แล้วแกน 0 สามารถใช้กับทุกสิ่งอื่นได้

ต่อไปนี้การสอนที่นี่มันควรจะง่ายเหมือน:

$ sudo cset shield -c 1-3
cset: --> shielding modified with:
cset: "system" cpuset of CPUSPEC(0) with 105 tasks running
cset: "user" cpuset of CPUSPEC(1-3) with 0 tasks running

ดังนั้นตอนนี้เรามี "shield" ซึ่งแยกได้ (user cset) และ core 0 สำหรับทุกอย่าง (system cset)

เอาล่ะดูดีมาก htopตอนนี้ให้ดูที่ กระบวนการทั้งหมดควรย้ายไปยัง CPU 0:

csets

ฮะ? กระบวนการบางอย่างจะแสดงเป็นทำงานบนแกนป้องกัน ในการแยกแยะกรณีที่ฮ็อพมีข้อผิดพลาดฉันก็ลองใช้tasksetเพื่อตรวจสอบความสัมพันธ์ของรูปแบบที่แสดงว่าอยู่ในโล่

บางทีงานเหล่านั้นอาจไม่สามารถเคลื่อนย้ายได้ ลองถอนกระบวนการโดยพลการแสดงว่าทำงานบน CPU3 (ซึ่งควรอยู่ใน shield) ในhtopและดูว่ามันจะปรากฏใน cgroup ระบบตามcset:

$ cset shield -u -v | grep 864
   root       864     1 Soth [gmain]
   vext01    2412  2274 Soth grep 864 

อ๋อที่ทำงานบนระบบ cgroup csetตาม ดังนั้นhtopและcsetไม่เห็นด้วย

แล้วเกิดอะไรขึ้นที่นี่? ใครที่ฉันสามารถไว้วางใจ: ซีพียูชอบพอ ( htop/ taskset) หรือcset?

ฉันสงสัยว่าคุณไม่ควรใช้csetและชอบใจกัน บางทีโล่ทำงานได้ดีและฉันควรละเว้นมาสก์ความสัมพันธ์และhtopผลลัพธ์ ฉันพบความสับสนนี้ ใครบางคนสามารถส่องแสงบ้างไหม?


คุณใช้การกระจายแบบไหน ฉันถามเพราะเครื่องมือและเวิร์กโฟลว์แตกต่างกันขึ้นอยู่กับระบบปฏิบัติการและเวอร์ชัน
ewwhite

มันเป็นระบบเดเบียน 8
Edd Barrett

ตกลง. ในโลก Redhat เรามีnumactlและcgconfigและcgrules/ cgredเพื่อปรับปรุงสิ่งที่คุณทำ สิ่งเหล่านี้อาจใช้ได้สำหรับ Debian ที่มีงานบางอย่าง
ewwhite

คำตอบ:


5

จากเอกสาร cpusets :

การเรียกไปยัง sched_setaffinity ถูกกรองไปยัง CPU ที่อนุญาตใน cpuset ของภารกิจนั้นเท่านั้น

นี่หมายถึงว่ามาสก์ความสัมพันธ์ของ CPU นั้นถูกตัดกับ cpus ใน cgroup ที่กระบวนการเป็นสมาชิก

เช่นถ้ามาสก์ความสัมพันธ์ของกระบวนการรวมคอร์ {0, 1, 3} และกระบวนการกำลังทำงานอยู่ในระบบ cgroup ซึ่งถูก จำกัด ไว้ที่คอร์ {1, 2} ดังนั้นกระบวนการจะถูกบังคับให้ทำงานบนคอร์ 1

ฉันแน่ใจว่า 99% ว่าhtopผลลัพธ์ไม่ถูกต้องกับความจริงที่ว่ากระบวนการไม่ได้ตื่นขึ้นมาตั้งแต่กลุ่ม cg ถูกสร้างขึ้นและการแสดงจะแสดงแกนสุดท้ายที่กระบวนการทำงาน

ถ้าฉันเริ่มเป็นกลุ่มก่อนที่จะสร้างโล่ของฉันเป็นกลุ่มส้อมสองครั้ง (ด้วยเหตุผลบางอย่าง) และเด็กที่ลึกที่สุดกำลังทำงานบนแกน 2 ถ้าฉันทำโล่แล้วนอน vim (ctrl + z) และปลุกมันกระบวนการทั้งสองมี ย้ายไปที่แกน 0 ฉันคิดว่านี่เป็นการยืนยันสมมติฐานที่htopแสดงข้อมูลเก่า

คุณยังสามารถตรวจสอบ/proc/<pid>/statusและดูcpus_allowed_*ฟิลด์

เช่นฉันมีconsole-kit-daemonกระบวนการ (pid 857) ที่นี่แสดงใน htop ว่าทำงานบน core 3 แต่ใน/proc/857/status:

Cpus_allowed:   1
Cpus_allowed_list:      0

ฉันคิดว่านี่เป็นสิ่งที่บอกว่ามาสก์ความสัมพันธ์คือ 0x1 ซึ่งอนุญาตให้ทำงานบนแกนหลัก 1 เท่านั้นเนื่องจากกลุ่ม cg: คือจุดตัด ({0,1,2,3}, {0}) = {0}

ถ้าทำได้ฉันจะเปิดคำถามทิ้งไว้สักครู่เพื่อดูว่ามีคำตอบใดที่ดีกว่านี้หรือไม่

ขอบคุณ @davmac ที่ช่วยเหลือสิ่งนี้ (บน irc)


1
คุณถูกต้องข้อมูลที่แสดงใน HTOP ไม่ใช่สิ่งที่กระบวนการหลักเป็นอยู่ในขณะนี้ แต่เป็นแกนหลักสุดท้ายที่กำหนดไว้ใน (เหมือนกันทุกสิ่งที่ใช้อินเทอร์เฟซเดียวกันสำหรับรวบรวมข้อมูล)
Austin Hemmelgarn
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.