ความจุคือจำนวนทรัพยากรทั้งหมด (CPU, GPU ฯลฯ) ที่อุปกรณ์ครอบครองในช่วงเวลาหนึ่ง หน้านี้อธิบายวิธีการระบุและแก้ไขปัญหาความจุที่เกี่ยวข้องกับความจุ
ผู้ว่าฯ ตอบสนองช้า
เพื่อหลีกเลี่ยงปัญหา Jank ตัวควบคุมความถี่ของ CPU จะต้องสามารถตอบสนองได้อย่างรวดเร็วต่อเวิร์กโหลดที่มีปริมาณมหาศาล แอปพลิเคชัน UI ส่วนใหญ่มีรูปแบบพื้นฐานเดียวกัน:
- ผู้ใช้กำลังอ่านหน้าจอ
- ผู้ใช้สัมผัสหน้าจอ: แตะปุ่ม เลื่อน ฯลฯ
- เลื่อนหน้าจอ เปลี่ยนกิจกรรม หรือทำให้เคลื่อนไหวในลักษณะใดลักษณะหนึ่งเพื่อตอบสนองต่ออินพุต
- ระบบหยุดทำงานเมื่อมีการแสดงเนื้อหาใหม่
- ผู้ใช้กลับไปอ่านหน้าจอ
อุปกรณ์ Pixel และ Nexus ใช้การเพิ่มระบบสัมผัสเพื่อปรับเปลี่ยนพฤติกรรมของตัวควบคุมความถี่ของ CPU (และตัวกำหนดเวลา) เมื่อสัมผัส เพื่อหลีกเลี่ยงการลาดช้าไปสู่ความถี่สัญญาณนาฬิกาที่สูง (ซึ่งอาจทำให้อุปกรณ์หลุดเฟรมเมื่อสัมผัส) การเพิ่มการสัมผัสมักจะตั้งค่าความถี่ขั้นต่ำบน CPU เพื่อให้แน่ใจว่าความจุ CPU มากมายจะพร้อมใช้งานเมื่อสัมผัส พื้นจะคงอยู่ระยะหนึ่งหลังจากสัมผัส (ปกติประมาณสองวินาที)
Pixel ยังใช้ schedtune cgroup ที่ได้รับจาก Energy Aware Scheduling (EAS) เป็นสัญญาณเพิ่มการสัมผัสเพิ่มเติม: แอปพลิเคชันอันดับต้นๆ จะมีน้ำหนักเพิ่มขึ้นผ่าน schedtune เพื่อให้แน่ใจว่าจะมีความจุของ CPU เพียงพอที่จะทำงานได้อย่างรวดเร็ว Nexus 5X และ 6P มีช่องว่างด้านประสิทธิภาพที่ใหญ่กว่ามากระหว่างคลัสเตอร์ CPU เล็กและใหญ่ (A53 และ A57 ตามลำดับ) มากกว่า Pixel ที่ใช้ Kryo CPU เราพบว่าคลัสเตอร์ CPU เล็กๆ นั้นไม่เพียงพอสำหรับการเรนเดอร์ UI ที่ราบรื่นเสมอไป โดยเฉพาะอย่างยิ่งเมื่อพิจารณาถึงแหล่งที่มาของความกระวนกระวายใจอื่นๆ บนอุปกรณ์
ดังนั้น บน Nexus 5X และ 6P การเพิ่มการสัมผัสจะปรับเปลี่ยนพฤติกรรมของตัวกำหนดเวลาเพื่อให้แอปพลิเคชันเบื้องหน้ามีโอกาสย้ายไปยังคอร์ขนาดใหญ่มากขึ้น (ซึ่งมีแนวคิดคล้ายกับพื้นบนความถี่ของ CPU) หากไม่มีการเปลี่ยนแปลงตัวกำหนดเวลาเพื่อทำให้แอปพลิเคชันเบื้องหน้ามีแนวโน้มที่จะย้ายไปยังคลัสเตอร์ CPU ขนาดใหญ่ แอปพลิเคชันเบื้องหน้าอาจมีความจุของ CPU ไม่เพียงพอที่จะเรนเดอร์จนกว่าตัวกำหนดเวลาจะตัดสินใจโหลดสมดุลเธรดไปยังแกน CPU ขนาดใหญ่ ด้วยการเปลี่ยนลักษณะการทำงานของตัวกำหนดเวลาระหว่างการเพิ่มการสัมผัส มีแนวโน้มมากขึ้นที่เธรด UI จะทำงานบนคอร์ขนาดใหญ่ทันที และหลีกเลี่ยงปัญหาการทำงานหนักในขณะที่ไม่ได้บังคับให้ทำงานบนคอร์ขนาดใหญ่เสมอไป ซึ่งอาจส่งผลกระทบอย่างรุนแรงต่อการใช้พลังงาน
การควบคุมปริมาณความร้อน
การควบคุมปริมาณความร้อนเกิดขึ้นเมื่ออุปกรณ์ต้องลดเอาท์พุตการระบายความร้อนโดยรวม ซึ่งโดยปกติจะดำเนินการโดยการลดนาฬิกา CPU, GPU และ DRAM ไม่น่าแปลกใจเลยที่สิ่งนี้มักส่งผลให้เกิดปัญหาเนื่องจากระบบอาจไม่สามารถให้ความจุเพียงพอที่จะเรนเดอร์ภายในช่วงเวลาที่กำหนดได้อีกต่อไป วิธีเดียวที่จะหลีกเลี่ยงการควบคุมปริมาณความร้อนคือการใช้พลังงานน้อยลง มีวิธีดำเนินการไม่มากนัก แต่จากประสบการณ์ของเรากับ SOC ที่ผ่านมา เรามีคำแนะนำบางประการสำหรับผู้จำหน่ายระบบ
อันดับแรก เมื่อสร้าง SOC ใหม่ด้วยสถาปัตยกรรม CPU ที่แตกต่างกัน ตรวจสอบให้แน่ใจว่าเส้นโค้งประสิทธิภาพ/W ของคลัสเตอร์ CPU ทับซ้อนกัน เส้นโค้งประสิทธิภาพ/W โดยรวมสำหรับโปรเซสเซอร์ทั้งหมดควรเป็นเส้นต่อเนื่อง ความไม่ต่อเนื่องในกราฟ perf/W บังคับให้ผู้จัดกำหนดการและผู้ควบคุมความถี่คาดเดาว่าเวิร์กโหลดต้องการอะไร เพื่อป้องกันไม่ให้เกิดปัญหา ตัวกำหนดเวลาและผู้ควบคุมความถี่ทำผิดพลาดในด้านการให้เวิร์กโหลดมีความจุมากกว่าที่ต้องการ ส่งผลให้เกิดการใช้พลังงานมากเกินไป ซึ่งส่งผลให้ควบคุมปริมาณความร้อน
ลองนึกภาพ SOC สมมุติที่มีคลัสเตอร์ CPU สองคลัสเตอร์:
- คลัสเตอร์ 1 ซึ่งเป็นคลัสเตอร์ขนาดเล็กสามารถใช้จ่ายไฟได้ระหว่าง 100-300mW และได้คะแนน 100-300 ในเกณฑ์มาตรฐานปริมาณงาน ขึ้นอยู่กับนาฬิกา
- คลัสเตอร์ 2 ซึ่งเป็นคลัสเตอร์ขนาดใหญ่สามารถใช้จ่ายไฟได้ระหว่าง 1,000 ถึง 1600mW และได้คะแนนระหว่าง 800 ถึง 1200 ในเกณฑ์มาตรฐานปริมาณงานเดียวกัน ขึ้นอยู่กับนาฬิกา
ในเกณฑ์มาตรฐานนี้ คะแนนที่สูงกว่าจะเร็วกว่า แม้ว่าจะไม่เป็นที่ต้องการมากกว่าช้าลง แต่เร็วขึ้น == การใช้พลังงานมากขึ้น
หากผู้จัดกำหนดการเชื่อว่าปริมาณงาน UI จะต้องมีคะแนนเทียบเท่ากับ 310 ในการวัดประสิทธิภาพปริมาณงานนั้น ตัวเลือกที่ดีที่สุดในการหลีกเลี่ยงปัญหา jak คือการรันคลัสเตอร์ขนาดใหญ่ที่ความถี่ต่ำสุด ซึ่งสิ้นเปลืองพลังงานอย่างมาก (ขึ้นอยู่กับพฤติกรรมของ cpuidle และการแข่งขันที่จะไม่ได้ใช้งาน SOC ที่มีกราฟ perf/W ต่อเนื่องจะปรับให้เหมาะสมได้ง่ายกว่า)
ประการที่สอง ใช้ cpusets ตรวจสอบให้แน่ใจว่าคุณได้เปิดใช้งาน cpusets ในเคอร์เนลของคุณและใน BoardConfig.mk คุณต้องตั้งค่าการกำหนด cpuset จริงใน init.rc เฉพาะอุปกรณ์ของคุณด้วย ผู้จำหน่ายบางรายปล่อยให้สิ่งนี้ถูกปิดการใช้งานใน BSP ของตนโดยหวังว่าพวกเขาจะสามารถใช้คำแนะนำอื่น ๆ เพื่อมีอิทธิพลต่อพฤติกรรมของตัวกำหนดเวลาได้ เรารู้สึกว่ามันไม่สมเหตุสมผล cpusets มีประโยชน์ในการตรวจสอบให้แน่ใจว่ามีการทำโหลดบาลานซ์ระหว่าง CPU ในลักษณะที่สะท้อนถึงสิ่งที่ผู้ใช้กำลังทำบนอุปกรณ์จริงๆ
ActivityManager กำหนดแอปให้กับชุด CPU ต่างๆ ตามความสำคัญสัมพัทธ์ของแอปเหล่านั้น (ด้านบน เบื้องหน้า พื้นหลัง) โดยที่แอปพลิเคชันที่สำคัญกว่าจะสามารถเข้าถึงแกน CPU ได้มากขึ้น ซึ่งช่วยรับประกันคุณภาพของบริการสำหรับแอปเบื้องหน้าและแอปยอดนิยม
cpusets มีประโยชน์ในการกำหนดค่า CPU ที่เป็นเนื้อเดียวกัน แต่คุณไม่ควรจัดส่งอุปกรณ์ที่มีการกำหนดค่า CPU ที่ต่างกันโดยไม่เปิดใช้งาน cpusets Nexus 6P เป็นโมเดลที่ดีสำหรับวิธีใช้ชุดซีพียูในการกำหนดค่า CPU ที่ต่างกัน ใช้สิ่งนั้นเป็นพื้นฐานสำหรับการกำหนดค่าอุปกรณ์ของคุณ
ชุดซีพียูยังให้ข้อได้เปรียบด้านพลังงานโดยทำให้แน่ใจว่าเธรดพื้นหลังที่ไม่สำคัญต่อประสิทธิภาพการทำงานจะไม่ได้รับโหลดที่สมดุลกับคอร์ CPU ขนาดใหญ่ ซึ่งพวกเขาสามารถใช้พลังงานได้มากขึ้นอย่างมากโดยไม่เกิดประโยชน์ใดๆ ที่ผู้ใช้รับรู้ ซึ่งสามารถช่วยหลีกเลี่ยงการควบคุมปริมาณความร้อนได้เช่นกัน แม้ว่าการควบคุมปริมาณความร้อนเป็นปัญหาด้านความจุ การปรับปรุงความกระวนกระวายใจมีผลกระทบอย่างมากต่อประสิทธิภาพของ UI เมื่อควบคุมปริมาณความร้อน เนื่องจากระบบจะทำงานใกล้กับความสามารถในการเรนเดอร์ 60FPS มากขึ้น จึงใช้เวลากระวนกระวายใจน้อยลงในการทำให้เฟรมหลุด