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