Skip to content
ปัจจุบันแอปพลิเคชัน (โดยเฉพาะมัลติมีเดีย) ต้องการประสิทธิภาพสูงขึ้น จึงมีการรวมหน่วยประมวลผลหลายตัวไว้ในชิปเดียวเรียกว่า Multiprocessor Systems-on-Chip (MPSoC) ซึ่งสื่อสารกันผ่าน Network-on-Chip (NoC).ระบบ MPSoC สมัยใหม่มักใช้ หน่วยประมวลผลที่หลากหลาย (เช่น GPP, DSP, ASIC ฯลฯ) เพื่อประหยัดพื้นที่และพลังงาน รวมถึงรองรับการปรับแรงดันไฟฟ้า-ความถี่ (DVFS) เพื่อช่วยลดการใช้พลังงาน.
การลดขนาดทรานซิสเตอร์และการเพิ่มความถี่ ทำให้โอกาสเกิดข้อผิดพลาดทั้งชั่วคราวและถาวรเพิ่มขึ้นใน MPSoCถ้าฮาร์ดแวร์บางส่วนเสียหายถาวร (permanent fault) แอปพลิเคชันต้องจัดการให้ระบบยังคงทำงานได้ โดยอาจยอมรับ "การลดลงของประสิทธิภาพ" (degradation) ในบางระดับการจัดการข้อผิดพลาดเดิมนิยมใช้ฮาร์ดแวร์สำรอง ซึ่งเพิ่มต้นทุนด้านพื้นที่และพลังงาน การใช้ "เทคนิคซอฟต์แวร์" เช่น การย้ายงาน (task migration) เป็นแนวทางที่นิยมเพื่อความคุ้มค่ามากขึ้น
เมื่อมีแกนประมวลผลเสีย งานจะถูกย้ายไปแกนที่ยังใช้งานได้ การเลือกแกนใหม่ต้องคิดถึงพลังงานที่ใช้ใน "การสื่อสารระหว่างงาน" ด้วยหากแกนรับงานใหม่เพิ่มขึ้น อาจต้องปรับแรงดัน/ความถี่สูงขึ้นเพื่อให้ยังรักษาความเร็วการทำงาน (throughput) ตามที่ต้องการ นั่นทำให้ปัญหาการ "จัดสรรงาน-พลังงาน-ความทนทาน" เป็นหัวข้อวิจัยสำคัญ
งานนี้เน้นแก้ปัญหา: จะกระจายงานแอปฯ ไปยังแกนต่างๆ ของ MPSoC อย่างไร ให้ใช้พลังงานน้อยที่สุด ขณะที่ยังมั่นใจว่าแอปฯ ทำงานเร็วพอ (throughput) ในทุกกรณีที่แกนเสียได้สมมุติว่า MPSoC และโครงร่างฮาร์ดแวร์ (floorplan) กำหนดมาแล้ว งานวิจัยนี้เน้นข้อผิดพลาดชนิดถาวรเป็นหลักเป็นงานแรกที่พยายาม จัดสรรงานโดยคิดรวม throughput, พลังงานคำนวณ, พลังงานสื่อสาร สำหรับกรณีที่มีความผิดพลาดแบบ reactive fault tolerance ในระบบ heterogeneous MPSoC
เสนอวิธี จัดสรรและกำหนดงาน โดยมองทั้งพลังงานคำนวณและพลังงานการสื่อสาร ระหว่างแกน โดยยังคง throughput ตามต้องการเสนอเทคนิคการ schedule เพื่อลด overhead ในการสร้างและจัดเก็บ schedule ที่ runtimeเสนอ heuristic ลดเวลาสำรวจ design space (การเลือกชุดการจัดสรรแบบต่างๆ)เสนอการจัดสรรงานที่คำนึงถึง floorplan ของฮาร์ดแวร์
มีงานเด่นในเรื่องการจัดสรรงานเพื่อลดพลังงานบน MPSoC แบบ embedded เช่น:Singh et al. และ Mandelli et al.: เน้นจัดสรรงานให้เหมาะกับการสื่อสาร ใช้ heuristic เพื่อประหยัดพลังงานการสื่อสาร แต่ ไม่ได้คำนึงถึงพลังงานจากการคำนวณ (computation energy).Goh et al. และ Schranzhofer et al.: เสนอเทคนิคลดพลังงานโดยปรับค่าไฟ/ความถี่ (DVFS) แต่ไม่ได้คิดถึงการจัดวางแกน/โครงร่างฮาร์ดแวร์ (floorplanning) และการสื่อสารระหว่างงาน.เทคนิค "slack budgeting" (Hu & Marculescu): กระจายเวลาว่างให้แต่ละงานเพื่อปรับความถี่ลง ลดพลังงาน แต่ไม่มี consideration เรื่อง throughput degradationข้อจำกัดร่วม: งานเหล่านี้ ไม่ได้รองรับกรณีแกนเสีย (fault) ทำให้ไม่เหมาะสำหรับการ optimize เรื่องพลังงานร่วมกับ fault tolerance
มีการใช้เทคนิค ฮาร์ดแวร์ redundancy มาตั้งแต่เดิม แต่เริ่มมีการใช้วิธี ซอฟต์แวร์ เช่น task migration เพื่อความคุ้มค่าในการจัดการ faultมี 2 แนวทางหลัก:Proactive: ป้องกันหรือชะลอการเกิด fault เช่น การจัดการใช้งานให้ไม่หนักเกินไปReactive: รับมือเมื่อเกิดแกนเสียแล้ว เช่น task migration, scheduling ใหม่Reactive fault tolerance แบ่งเป็น 2 แบบRuntime: ตัดสินใจ migrate งานเมื่อเกิด fault จริง เช่น Al Faruque et al., Derin et al., Zhang et al. – มักใช้ algorithm ที่คอมพิวต์ง่าย แต่ไม่เสมอไปที่ throughput จะอยู่ในเกณฑ์ที่ต้องการDesign-time: เตรียมแผนการ mapping/มอบหมายงานไว้ล่วงหน้า (static) สำหรับแต่ละกรณีแกนเสีย เช่น Yang & Orailoglu, Lee et al., Huang et al., Das & Kumar – ทำให้สามารถใช้ algorithm ที่ซับซ้อนใน design-time แลกกับ schedule storage overhead ที่มากขึ้นงานเช่น Yang & Orailoglu: ใช้เทคนิค "band and band reconfiguration" แบ่งแกนเป็น band หากแกนเสียจะย้ายงานไป band ที่กำหนด ข้อจำกัดคือ throughput ไม่ได้รับประกันHuang et al.: ใช้ evolutionary algorithm scheduling slot แบบ reexecution เพื่อลด throughput degradation แต่เมื่อระบบต้องทน fault สูง schedule length จะยาวมากLee et al.: offline mapping, virtual mapping เพื่อช่วย migration ให้ได้ throughput สูงสุด แต่ไม่ได้ optimize migration overhead ทำให้ migration cost เพิ่มขึ้น และ throughput ที่สูงกว่าเป้าหมายอาจเปลือง bufferDas & Kumar: ลด migration overhead กับ throughput degradation สำหรับ streaming application แต่ไม่ได้ optimize เรื่อง scheduling ทำให้เกิด schedule overhead ใน runtime หรือ storage overhead ใน design-timeข้อจำกัดร่วม: งานเหล่านี้มักไม่ optimize energy consumption รวมด้วย
Wei et al.: ใช้ ILP joint optimize energy กับเวลา (execution time) ที่รวม fault tolerance overhead (checkpointing) ไม่เหมาะกับ permanent faults เพราะไม่ได้แก้ปัญหา migration จริงHuang & Xu: scheduling เพื่อลดพลังงานและยืดอายุ system แต่ไม่ได้ optimize migration overhead, resource management หรือ throughput degradationDas et al.: minimize communication energy ใน migration แต่ไม่ได้ optimize computation energy และ schedule/mapping storage overhead
งานของ Yang & Orailoglu, Huang et al., Lee et al., Das & Kumar มีประเด็นสำคัญเกี่ยวกับการจัดสรรงานและ migration เมื่อเกิด permanent fault ใน MPSoCSingh et al., Mandelli et al., Schranzhofer et al. เด่นเรื่อง energy-aware mapping ซึ่งตรงกับโจทย์ของ paper นี้อย่างไรก็ตาม ทุกงานมีจุดอ่อนคือ ยังไม่ได้ optimize ทุกด้าน (energy, fault, throughput) พร้อมกัน ทำให้ paper นี้มีพื้นที่ในการเสนอแนวทางใหม่ที่ optimize ทั้งหมดร่วมกัน
Synchronous Dataflow Graphs (SDFGs) คือโมเดลกราฟที่นิยมใช้สำหรับออกแบบและวิเคราะห์แอปพลิเคชันประเภท DSP (Digital Signal Processing) และมัลติมีเดียบน MPSoCใน SDFG งานแต่ละชิ้น (task) จะเรียกว่า actor เป็น node ในกราฟ ส่วน edge คือ channel สำหรับส่งข้อมูลระหว่าง actorsActor จะอ่านข้อมูลจาก input port แล้วประมวลผล และส่งผลลัพธ์ออกทาง output port โดยในแต่ละรอบ (firing) จะใช้และผลิตจำนวน token ที่เท่าเดิมเสมอ (เรียกว่า port rate)
Actor สามารถทำงาน (firing) เมื่อมี token ใน input ครบตามเงื่อนไข และ buffer/พื้นที่ใน output เพียงพอedge หรือ channel อาจมี initial tokens (token เริ่มต้น) เพื่อ modeling cyclic dependency และ buffer spaceSDFGs สามารถวิเคราะห์ throughput, latency และ buffer requirements ได้ครบถ้วน
SDFG ช่วยคำนวณว่าแอปฯ ทำงานเร็วแค่ไหน (throughput): คำนวณเป็น period คือเวลาที่ใช้ต่อหนึ่งรอบงานในระบบในการวิเคราะห์ throughput จะใช้ repetition vector กำหนดว่าแต่ละ actor ทำงานกี่ครั้งต่อหนึ่งรอบสามารถจัดการ buffer ได้โดย modeling edge ที่วนกลับ (back edge) เพื่อกำหนดขนาด buffer ในระบบ
เทคนิคหลักสำหรับ scheduling SDFGs คือ self-timed execution: กำหนดลำดับและผู้รับผิดชอบงาน (mapping) ที่ดีไว้ล่วงหน้า จากนั้นให้แต่ละ actor firing ตามลำดับที่ออกแบบไว้โดยอาศัย worst-case execution timeการ fire จะเป็นของจริงตามลำดับที่กำหนด ใน runtime actor จะถูกดำเนินการตามลำดับนั้น (self-timed) ต่างจาก schedule แบบ static ตรงที่ self-timed รองรับความผันผวนของเวลาทำงานจริงแต่ละรอบได้ดีกว่า
Self-timed schedule มักจะมี phase ชั่วคราว (transient) ก่อนเข้าสู่ phase ทำงานปกติ (steady-state)Throughput จะได้จากค่าเฉลี่ยการ firing actor ในช่วง steady-stateทำให้ระบบ robust และรองรับความเปลี่ยนแปลง runtime ได้ดีเทคนิคนี้เหมาะกับ streaming application และใช้กับ DAG ได้ด้วยSDFG เป็นโมเดลกราฟที่เหมาะสำหรับงานที่มีการส่งข้อมูลต่อเนื่องและสัมพันธ์กันบนหลายแกนใน MPSoCช่วยให้ออกแบบ/วิเคราะห์การ mapping, scheduling, throughput และ buffer ได้ชัดเจนSelf-timed execution คือหัวใจของการ schedule SDFG ที่ทำให้ระบบมั่นใจได้ว่าทำงานต่อเนื่องแม้เกิด fault และ throughput ถูกควบคุมได้
ระบบเป้าหมายคือ heterogeneous MPSoC มีหลายแกนประมวลผล (cores) เชื่อมต่อกันด้วยโครงข่าย (เช่น mesh)แต่ละโซนบน chip อาจมี core ชนิดเหมือนกัน (เช่น DSP, GPP ฯลฯ) และ core แต่ละตัวอาจตั้ง ความถี่ ได้หลายระดับจุดสำคัญ: งานนี้พิจารณาตำแหน่ง core บนแผนผัง (floorplan-aware) เพื่อให้ mapping งานมี communication energy ต่ำที่สุดหาก mapping ไม่พิจารณาตำแหน่ง อาจทำให้ข้อมูลข้ามหลาย hops สิ้นเปลืองพลังงาน
กำหนดชุดสัญลักษณ์สำหรับจัดสรรงาน:จำนวน core (narc)จำนวน actor (napp)Mapping ของงาน (Mn) จะบอกว่า actor ใดไปอยู่ core ใด ใช้ความถี่เท่าไรมีตัวแปรระบุเหตุการณ์ที่ core เสีย (fault scenario) เพื่อเตรียม mapping สำรองทุก mapping ถูกบันทึกด้วย ID เฉพาะสำหรับอ้างอิงและสลับ mapping เวลาเกิด fault
พลังงานคำนวณ (computation energy) ของระบบคิดจาก:กำลังไฟฟ้าไดนามิก (dynamic power) ขึ้นกับ activity factor, ความถี่และแรงดันไฟ, ค่าประจุ ฯลฯเน้นลด dynamic power เป็นหลักการคำนวณพลังงานจะใช้แค่ steady-state phase เป็นหลัก (เนื่องจากทำงานนานกว่า transient phase)“Computation energy” ใน paper นี้คือพลังงานที่ใช้ในช่วง steady-state ของการทำงานแต่ละครั้ง
Communication energy คือพลังงานที่ใช้ส่งข้อมูลระหว่าง core ผ่าน NoCถ้าข้อมูลต้องข้ามหลาย hops (เช่นหลาย router หรือ switch) จะใช้พลังงานมากขึ้นจุดสำคัญคือ mapping "ระหว่าง core" ต้องออกแบบให้ข้อมูลวิ่งผ่าน hops น้อยที่สุดเพื่อลด communication energyพลังงานต่อบิตแบ่งเป็นส่วนที่ใช้ใน switch กับลิงก์ (สายสื่อสาร)
Migration overhead คือพลังงานที่ต้องใช้ย้ายงานจาก core ที่เสียไป (เช่นย้าย state/data/code ไป core อื่น)ปกติจะมีโมดูลช่วยย้ายงาน (TMM) ระดับระบบ ทำให้ย้ายได้รวดเร็วโดยไม่กระทบงานปกติพลังงานการ migration คิดจากขนาดข้อมูลของ actor ที่ถูกย้ายและระยะทาง (จำนวน hops)ในงานวิจัยนี้ พลังงาน migration ถือว่าน้อยมากเมื่อเทียบกับ computation/communication energy จึงมักละเลยในผลทดลองแต่สำหรับระบบที่ต้องการ uptime สูง สามารถนำ migration overhead ไปคิดรวมได้ปัญหาที่ paper นี้แก้คือ: จะจัดสรรงานแต่ละตัวบน core หลากชนิดใน MPSoC อย่างไรให้ใช้พลังงานคำนวณและพลังงานสื่อสาร “รวมกันน้อยที่สุด” เมื่อมีเหตุการณ์ core เสีย และยังคงให้ throughput ตามเงื่อนไขที่แอปพลิเคชันต้องการทุกส่วน (architecture, mapping, energy model) ถูกกำหนดให้รองรับกรณี core พังถาวร โดยพิจารณาทั้ง mapping สำรอง, พลังงานคำนวณ, พลังงานสื่อสาร และ migration overhead ในแต่ละเหตุการณ์
การออกแบบวิธีจัดสรรงาน/mapping เพื่อให้ MPSoC ทนทานต่อ fault และ ใช้พลังงานต่ำ จะทำ “ล่วงหน้า” (design-time/offline) พร้อมเตรียม mapping สำรองสำหรับแต่ละกรณี fault ที่อาจเกิดขึ้นเมื่อตรวจพบว่า core ใดเสีย system ก็จะสลับไปใช้ mapping ที่เตรียมไว้สำหรับ fault scenario นั้นทันที
Design-Time Analysisสำหรับทุกกรณีที่เกิด fault (fault scenario) จะสร้าง “mapping ที่เหมาะสมที่สุด” (optimal mapping) ที่ทั้งผ่านเกณฑ์ throughput และใช้พลังงานน้อยสุดMapping แต่ละแบบจะถูกเข้ารหัส (encode) ด้วย ID และเก็บไว้ในหน่วยความจำRuntime Migrationเมื่อ runtime ตรวจพบ fault จะแปลง scenario ที่พบเป็นรหัส mapping แล้วดึง mapping ที่เหมาะสมจากหน่วยความจำจากนั้น system จะทำ migration ย้ายงานจาก core ที่เสียไปยัง core สำรอง โดยอาศัย mapping ที่เตรียมไว้
วัฏจักรหลักของอัลกอริทึมคือการสร้าง mapping สำหรับแต่ละกรณี fault จาก core ที่เสีย (ตั้งแต่กรณีเสีย 1 core ไปจนถึงตามระดับ fault-tolerance ที่กำหนด)สำหรับแต่ละชุด scenario ที่อาจเกิดขึ้น:ดึง mapping ของ scenario ก่อนหน้า (กรณีเสีย core น้อยกว่า 1)เรียกฟังก์ชัน genMinEnergyMap เพื่อสร้าง mapping ใหม่สำหรับ scenario ที่มีการเสีย core เพิ่มขึ้น อีก 1 ตัวบันทึก mapping ใหม่ไว้ในฐานข้อมูล (HashMap) สำหรับ fault scenario นั้นทำซ้ำสำหรับทุกกรณีจนคบทุกช่วงของการเสีย coreทุก mapping ถูกสร้างแบบแบ่งขั้นจาก mapping ก่อนหน้า (ลดการค้นหาทำซ้ำ)สำหรับแต่ละ scenario จะแน่ใจได้ว่าจะได้ mapping ที่ throughput ไม่ต่ำกว่ากำหนดและใช้พลังงานต่ำที่สุด
จุดประสงค์คือ สร้าง mapping งานให้ทนการเสียของ core (fault-tolerant) และประหยัดพลังงานที่สุดสำหรับทุกกรณีที่อาจเกิดการเสีย coreดำเนินการ “ล่วงหน้า” (design-time): เตรียม mapping ไว้สำหรับทุก fault scenario—เมื่อ core ไหนเสีย runtime จะใช้ mapping ที่เตรียมไว้ทันที
กำหนดจำนวน fault ที่ทนได้ F (เช่น ทนได้สูงสุด 2 core เสีย)สำหรับแต่ละระดับ f (ตั้งแต่ 1 ถึง F) จะพิจารณากรณีเสีย core f ตัวทุกกรณี (เช่น เสีย core 1-2, 1-3, …)สำหรับแต่ละ scenario:2.1. เริ่มต้นด้วย mapping ของ scenario ก่อนหน้า (กรณีเสีย core น้อยกว่า 1 ตัว)2.2. ใช้ genMinEnergyMap เพื่อหาการกระจายงานใหม่บน core ที่เหลือ (โดยต้องย้ายงานจาก core ที่เสีย)2.3. เลือก mapping ที่ทั้งผ่าน throughput constraint และใช้พลังงานน้อยสุด2.4. บันทึก mapping สำหรับ scenario นี้ในฐานข้อมูล (HashMap)
มี 2 ส่วนหลัก:Mandatory Section:ย้ายงานทั้งหมดที่อยู่บน core ที่เสียไปยัง core ที่ยังใช้งานได้วิธีการ: ลองทุกการย้ายที่เป็นไปได้ (brute-force) และเลือก mapping เริ่มต้นที่ communication energy ต่ำที่สุดPerformance Section:ปรับแก้ mapping ที่ได้เพิ่มเติม โดย “remap” งานบางส่วน เพื่อให้ทั้ง throughput ถึงเป้าหมาย และ energy ลดลงอีกใช้วิธี iterative: ในแต่ละรอบจะ remap actor ที่ (เมื่อย้ายไป core และความถี่ใหม่แล้ว) ทำให้ energy ต่ำลงและไม่กระทบ throughputหยุด remap เมื่อไม่มีนักแสดงคนไหนย้ายได้โดยไม่ทำให้ throughput ต่ำกว่ากำหนดเก็บ mapping ที่ best energy สำหรับ scenario นี้
เลือก mapping งานสำหรับทุกกรณีการเสีย core โดยเริ่มย้ายงานที่จำเป็นก่อนจากนั้นพยายามปรับแก้ทีละน้อยๆ เพื่อให้ energy ของ mapping ลดลงจนได้ mapping ที่ดีที่สุดทุก mapping สำหรับแต่ละ scenario จะถูกจดจำไว้ นำไปใช้งาน runtime ทันทีเมื่อเจอ core เสียจริง
เมื่อ “core เสีย” ต้องหาวิธีย้ายงานให้ mapping ใหม่ทั้งทนทานและใช้พลังงานต่ำสุดวิธีนี้ใช้ heuristic แบ่งเป็น 2 ส่วนหลัก: ย้ายงานที่จำเป็นก่อน และปรับแก้ mapping เพื่อให้ energy น้อยที่สุด
เมื่อ core ใดเสีย งานทุกตัวบน core ที่เสียจะถูกย้ายไปแกนที่ยังเหลือในระบบลองทุกทางเลือกที่เป็นไปได้ (brute-force) เพื่อหาวิธีย้ายที่ communication energy ต่ำสุดการเลือกแบบนี้จะช่วยให้ energy ของ mapping ไม่บานปลายตั้งแต่เริ่มหลังได้ mapping เริ่มต้น จะวนปรับ remap งานแต่ละตัวซ้ำทีละตัว โดย:ทดสอบย้าย actor แต่ละตัวไปยัง core ที่ยังเหลือ และลองเปลี่ยนระดับความถี่ทุกครั้งที่ย้าย จะเช็ค throughput ว่ายังถึงเป้าหมายไหม และ energy ดีขึ้นหรือไม่ถ้าดีขึ้นคือ throughput ไม่ตกและพลังงานต่ำลง ก็เลือกการย้ายงานนั้นวนจนไม่มีการปรับ remap ที่ให้พลังงานลดได้อีกโดยไม่ทำให้ throughput ต่ำกว่าที่กำหนดmapping ที่สำเร็จนี้ถือเป็น “minimum energy mapping” สำหรับ scenario นี้
พิจารณาทุก actor และทุก core ที่ยังเหลือ พร้อมทุกระดับความถี่ที่ core รองรับปรับย้ายทีละ actor เลือกทั้ง destination core และ frequency โดยดูว่า energy และ throughput ดีขึ้นหรือไม่ใช้ฟังก์ชัน gradient ประเมินการย้ายแต่ละครั้ง (ดูว่านำไปสู่ energy ต่ำและ throughput ไม่ต่ำกว่ากำหนด)เลือกการย้ายที่ได้ gradient สูงสุด (ดีที่สุด) ในแต่ละรอบ
วิธีนี้เป็นการ “remap งานอย่างฉลาด” หลัง core เสีย โดยประเมินความคุ้มค่าต่อ throughput และ energy ทุกครั้งmapping ที่ได้จะถูกบันทึกไว้และนำไปใช้ทันทีเมื่อ core เสียจริงใน runtimeขั้นตอนนี้เป็นหัวใจสำคัญให้ระบบทั้งทนทานต่อ fault และประหยัดพลังงานในทุกสถานการณ์
เพื่อสร้าง mapping เริ่มต้นที่ให้พลังงานต่ำสุด ก่อนคำนึงถึงกรณี core เสียวิธีเดิม: ต้องสำรวจทุก mapping ที่เป็นไปได้ ทำให้เวลาในการคำนวณเติบโตอย่างรวดเร็ววิธีใหม่ใน paper นี้: ใช้ heuristic ที่มีประสิทธิภาพ ลดเวลาคำนวณโดยใช้กระบวนการ iterative remapping actor ทีละตัว
เริ่มต้นใช้อัลกอริทึม deterministic ที่รู้จัก (เช่น HEFT สำหรับ DAG หรือ SDF3 engine สำหรับ SDFG) เพื่อสร้าง mapping เริ่มแรกกระบวนการ iterative remapเช็ค actor แต่ละตัวว่าสามารถถูกย้ายไป core อื่น (พร้อม frequency ใหม่) เพื่อ "ลดพลังงาน" และ "throughput ยังสูงพอ" ได้หรือไม่ใช้ฟังก์ชัน RemapActor (ที่อธิบายไว้ใน Algorithm 3) เพื่อเลือก actor-core-frequency ที่ดีที่สุดในแต่ละรอบหากมีทางเลือกใหม่ที่ดีที่สุดก็ remap actor นั้นวนซ้ำจนไม่สามารถ remap ดีกว่าเดิมได้อีกผลลัพธ์mapping ที่ได้จากขั้นตอนนี้ถือเป็น “minimum energy initial mapping” ที่จะใช้เป็นจุดเริ่มต้นสำหรับกระบวนการ fault-tolerant mapping ในทุกกรณี core เสีย
ใช้ SDF3 engine เพื่อ mapping และ scheduling งานบน core ทั้งหมดแบบ steady-state (ยังไม่มีกรณี core เสีย)ใช้ RemapActor เพื่อปรับ mapping จนได้ mapping ที่ energy ต่ำกว่าเดิม (แต่ throughput ยังสูงพอ)จบเมื่อไม่มี actor ไหนที่ควร remap อีกmapping ที่ได้ถูกใช้เป็นฐานสำหรับการสร้าง mapping กรณี core เสียใน Algorithm 1, 2
วิธีสร้าง initial mapping แบบ iterative นี้ช่วยลดเวลาสำรวจ design space อย่างมากเมื่อเทียบกับ exhaustive searchทำให้ระบบตั้งหลักการเลือก mapping ที่พลังงานต่ำสุดเพื่อให้ครอบคลุม/ต่อยอดไปถึงกรณี core เสียในงาน fault-tolerant mapping
จัดลำดับการทำงานของ actors (tasks) บน core ต่างๆ ให้สอดคล้องกับ mapping ที่ออกแบบไว้ลด overhead ทั้งด้านเวลา (runtime schedule construction) และหน่วยความจำ (storage overhead) สำหรับ schedule ของทุกกรณีที่ core พัง (fault scenario)รับรองว่า throughput ณ runtime จะตรงกับที่วิเคราะห์ไว้ตอนออกแบบ
วิธี 1: เก็บ schedule สำหรับทุก fault scenario ล่วงหน้า (storage-based) แต่เปลืองเนื้อที่มากวิธี 2: สร้าง schedule ใหม่ทุกครั้งที่เกิด fault (construction-based) แต่เสียเวลา runtime มาก โดยเฉพาะใน streaming application
ใช้หลัก self-timed scheduling กับระบบมัลติโปรเซสเซอร์:เก็บแค่ mapping และลำดับ firing ของ actors ที่ถูกสร้างไว้สำหรับ uniprocessorเมื่อต้องกระจายงานไปหลาย core (multiprocessor) ให้นำ firing order เดิมมาแตกออกเป็นลำดับย่อยของแต่ละ coreถ้าเกิด core เสีย ให้ย้าย actor ทั้งหมด (พร้อม counter การ firing ที่เหลือ) ไป core ใหม่ แล้วทำ self-timed scheduling ต่อทันที (ไม่ deadlock)ช่วยลดทั้ง storage + runtime overhead ได้มาก (ลดเนื้อที่เก็บ schedule ถึง 92%, ลดเวลาสร้างใหม่ runtime ถึง 95%)
สร้าง uniprocessor schedules หลายแบบ (ด้วยวิธี list scheduling เช่น ETF, DLS ฯลฯ)สำหรับแต่ละ schedule ให้ประเมินว่ารองรับ fault scenario ไหนได้ throughput ถึงเป้าหมายบ้างเลือก schedule ที่รองรับจำนวน fault scenario ได้มากที่สุดเป็น schedule หลักสำหรับ scenario นั้นๆ
More
Share
Explore
สรุป Energy-Aware Task Mapping and Scheduling for Reliable Embedded Computing Systems
1 Introduction
1. การเติบโตของ MPSoCs และปัญหาใหม่
2. ความท้าทายเรื่องความทนทานและความผิดพลาดของฮาร์ดแวร์
3. การจัดสรรงานและพลังงาน
4. ขอบเขตของงานวิจัยนี้
5. จุดเด่น/นวัตกรรมของงานนี้
2. Related Work
1. งานวิจัยด้าน Energy Optimization
2. งานวิจัยด้าน Fault Tolerance
3. งานวิจัยล่าสุดที่ optimize Energy & Fault Tolerance พร้อมกัน
Highlight ที่เกี่ยวข้องกับเป้าหมายของ paper นี้:
3 Introduction to Synchronous Dataflow Graphs (SDFGs)
1. SDFG คืออะไร?
2. วิธีการทำงานของ SDFG
3. แนวคิดสำคัญและประโยชน์
4. การ schedule ที่ใช้กับ SDFG
5. คุณสมบัติและข้อดีของ self-timed scheduling
ใจความสำคัญ
4 Problem Formulation
4.1 Architecture Model
4.2 Mapping Representation
4.3 Computation Energy Modeling of an Application
4.4 Communication Energy Modeling of Applications
4.5 Migration Overhead Modeling of Application
ใจความสำคัญ
5 Design Methodology
กระบวนการหลัก
ALGORITHM 1: Generate Fault-Tolerant Mappings
จุดเด่น
5.1 Fault-Tolerant Mapping Generation
1. หลักการโดยรวม
2. วิธีการสร้าง Fault-Tolerant Mapping (ALGORITHM 1: Generate Fault-Tolerant Mappings)
ไอเดียสำคัญ: mapping ทุกระดับ (จำนวน core เสียมากขึ้น) จะขึ้นกับ mapping ของ scenario ก่อนหน้า เพื่อไม่ต้องสร้าง mapping ใหม่จากศูนย์
Algorithm 2: GenMinEnergyMap (การสร้าง mapping ที่ประหยัดพลังงานที่สุดสำหรับแต่ละ scenario)
สรุปภาพรวมแบบง่าย:
5.2 Generate Minimum Energy Mapping
1. เป้าหมายหลัก
2. กระบวนการหลัก
Mandatory Section (ขั้นตอนจำเป็น):
Performance Section (ปรับแก้เพิ่มเติม):
ALGORITHM 3: RemapActor (การเลือก actor, core, frequency ที่ดีที่สุด)
ใจความสำคัญ
5.3 Generate Initial Mapping
เป้าหมายหลักของ 5.3
หลักการกระบวนการ Generate Initial Mapping
Algorithm 4: Generate Initial Mapping
ใจความสำคัญ
6 Scheduling
เป้าหมายของส่วน Scheduling
ปัญหาของวิธีดั้งเดิม
วิธีใหม่ที่นำเสนอ (Self-Timed Execution-Based Scheduling)
กระบวนการสร้าง schedule (Algorithm 5)
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.