Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
©ARM 2017
SCHED_DEADLINE
Ongoing development and new features
Juri Lelli
Linaro Connect BUD17, Budapest (Hungary)
ARM Ltd....
©ARM 20172
Agenda
 Deadline scheduling (SCHED_DEADLINE)
 Why is development now happening (out of the blue?)
 Bandwidth...
©ARM 20173
CHAPER 1
What and Why
©ARM 20174
Agenda
 Deadline scheduling (SCHED_DEADLINE)
 Why is development now happening (out of the blue?)
 Bandwidth...
©ARM 20175
Deadline scheduling (previously on ...)
 mainline since v3.14
30 March 2014 (~3y ago)
 it’s not only about de...
©ARM 20176
Agenda
 Deadline scheduling (SCHED_DEADLINE)
 Why is development now happening (out of the blue?)
 Bandwidth...
©ARM 20177
Why is development now happening
 Energy Aware Scheduling (EAS)
 extends the Linux kernel scheduler and power...
©ARM 20178
CHAPTER 2
Let’s reclaim!
©ARM 20179
Agenda
 Deadline scheduling (SCHED_DEADLINE)
 Why is development now happening (out of the blue?)
 Bandwidth...
©ARM 201710
Bandwidth Reclaiming
 PROBLEM
 tasks’ bandwidth is fixed (can only be changed with sched_setattr())
 what i...
©ARM 201711
Bandwidth Reclaiming (cont.)
 Greedy Reclamation of Unused Bandwidth (GRUB)1
 3 components2
 tracking of ac...
©ARM 201712
Bandwidth Reclaiming (results)
 Task1 (6ms, 20ms)
constant execution time
of 5ms
 Task2 (45ms, 260ms)
experi...
©ARM 201713
Bandwidth Reclaiming (results)
 Task1 (6ms, 20ms)
constant execution time
of 5ms
 Task2 (45ms, 260ms)
experi...
©ARM 201714
Bandwidth Reclaiming (results)
 Task1 (6ms, 20ms)
constant execution time
of 5ms
 Task2 (45ms, 260ms)
experi...
©ARM 201715
Bandwidth Reclaiming (results)
 Task1 (6ms, 20ms)
constant execution time
of 5ms
 Task2 (45ms, 260ms)
experi...
©ARM 201716
CHAPTER 3
Rock around the Clock (... and CPU)
©ARM 201717
Agenda
 Deadline scheduling (SCHED_DEADLINE)
 Why is development now happening (out of the blue?)
 Bandwidt...
©ARM 201718
Frequency/CPU scaling
 Reservation runtime needs scaling according to frequency and CPU max
capacity
 for fr...
©ARM 201719
Agenda
 Deadline scheduling (SCHED_DEADLINE)
 Why is development now happening (out of the blue?)
 Bandwidt...
©ARM 201720
Driving frequency selection
 scaling clock frequency, while meeting tasks’ requirements (deadlines)
 schedul...
©ARM 201721
CHAPTER 4
Groupies
©ARM 201722
Agenda
 Deadline scheduling (SCHED_DEADLINE)
 Why is development now happening (out of the blue?)
 Bandwidt...
©ARM 201723
Group scheduling
 Currently, one to one association between tasks and reservations
 Sometime it might be bet...
©ARM 201724
Group scheduling
 Hierarchical means
 first level is EDF
 second level is RT (FIFO/RR)
 Should eventually ...
©ARM 201725
Group scheduling
 On multiprocessors
 One DEADLINE group entity per CPU
 Coexists with single DEADLINE enti...
©ARM 201726
Group scheduling
 On multiprocessors
 One DEADLINE group entity per CPU
 Coexists with single DEADLINE enti...
©ARM 201727
CHAPTER 5
It IS bright!
©ARM 201728
Agenda
 Deadline scheduling (SCHED_DEADLINE)
 Why is development now happening (out of the blue?)
 Bandwidt...
©ARM 201729
Future
 NEAR
 experimenting with Android
 reclaiming by demotion towards lower priority class
 capacity aw...
The trademarks featured in this presentation are registered and/or unregistered trademarks of ARM Limited
(or its subsidia...
Prochain SlideShare
Chargement dans…5
×

BUD17-307: SCHED_DEADLINE: ongoing development and new features

818 vues

Publié le

"Session ID: BUD17-307
Session Name: SCHED_DEADLINE: ongoing development and new features - BUD17-307
Speaker: Juri Lelli
Track: Power Management


★ Session Summary ★
After deadline scheduling for processes (SCHED_DEADLINE scheduling policy) has been merged in the Linux kernel in Mar-2014 (version 3.14) a considerable effort has been put into actively maintaining it, but no further development really happened after that date, until recently.

In this presentation, Juri Lelli, after giving a (very briefly) review of the current set of features, will deep dive into the details of all the new features currently under development: CPU capacity and clock frequency scaling, bandwidth reclaiming, coupling with clock frequency selection and cgroups support.
---------------------------------------------------
★ Resources ★
Event Page: http://connect.linaro.org/resource/bud17/bud17-307/
Presentation: https://www.slideshare.net/linaroorg/bud17307-scheddeadline-ongoing-development-and-new-features
Video: https://youtu.be/YXjWDjzzhV8
---------------------------------------------------

★ Event Details ★
Linaro Connect Budapest 2017 (BUD17)
6-10 March 2017
Corinthia Hotel, Budapest,
Erzsébet krt. 43-49,
1073 Hungary

---------------------------------------------------
Keyword: Power-management, sched-deadline
http://www.linaro.org
http://connect.linaro.org
---------------------------------------------------
Follow us on Social Media
https://www.facebook.com/LinaroOrg
https://twitter.com/linaroorg
https://www.youtube.com/user/linaroorg?sub_confirmation=1
https://www.linkedin.com/company/1026961"

Publié dans : Technologie
  • Identifiez-vous pour voir les commentaires

BUD17-307: SCHED_DEADLINE: ongoing development and new features

  1. 1. ©ARM 2017 SCHED_DEADLINE Ongoing development and new features Juri Lelli Linaro Connect BUD17, Budapest (Hungary) ARM Ltd. 08/03/2017
  2. 2. ©ARM 20172 Agenda  Deadline scheduling (SCHED_DEADLINE)  Why is development now happening (out of the blue?)  Bandwidth reclaiming  Frequency/CPU scaling of reservation parameters  Coupling with frequency selection  Group scheduling  Future
  3. 3. ©ARM 20173 CHAPER 1 What and Why
  4. 4. ©ARM 20174 Agenda  Deadline scheduling (SCHED_DEADLINE)  Why is development now happening (out of the blue?)  Bandwidth reclaiming  Frequency/CPU scaling of reservation parameters  Coupling with frequency selection  Group scheduling  Future
  5. 5. ©ARM 20175 Deadline scheduling (previously on ...)  mainline since v3.14 30 March 2014 (~3y ago)  it’s not only about deadlines  RT scheduling policy  explicit per-task latency constraints  avoids starvation  enriches scheduler’s knowledge about QoS requirements  EDF + CBS  resource reservation mechanism  temporal isolation  ELC16 presentation https://goo.gl/OVspuI Linux scheduler deadline.c rt.c fair.c SCHED_ DEADLINE SCHED_RR SCHED_FIFO SCHED_ IDLE SCHED_ BATCH SCHED_ NORMAL
  6. 6. ©ARM 20176 Agenda  Deadline scheduling (SCHED_DEADLINE)  Why is development now happening (out of the blue?)  Bandwidth reclaiming  Frequency/CPU scaling of reservation parameters  Coupling with frequency selection  Group scheduling  Future
  7. 7. ©ARM 20177 Why is development now happening  Energy Aware Scheduling (EAS)  extends the Linux kernel scheduler and power management to make it fully power/performance aware (https://goo.gl/vQbUOu)  scheduler modifications pertain to SCHED_NORMAL (so far)  Android Common Kernel  EAS has been merged last year (https://goo.gl/FXCdAX)  performance usually means meeting latency requirements  considerable usage (and modifications) of SCHED_FIFO  SCHED_DEADLINE seems to be a better fit and mainline adoption of required changes should be less controversial  Joint collaboration between ARM and Scuola Superiore Sant’Anna of Pisa
  8. 8. ©ARM 20178 CHAPTER 2 Let’s reclaim!
  9. 9. ©ARM 20179 Agenda  Deadline scheduling (SCHED_DEADLINE)  Why is development now happening (out of the blue?)  Bandwidth reclaiming  Frequency/CPU scaling of reservation parameters  Coupling with frequency selection  Group scheduling  Future
  10. 10. ©ARM 201710 Bandwidth Reclaiming  PROBLEM  tasks’ bandwidth is fixed (can only be changed with sched_setattr())  what if tasks occasionally need more bandwidth? e.g., occasional workload fluctuations (network traffic, rendering of particularly heavy frame, etc)  SOLUTION (proposed*)  bandwidth reclaiming:allow tasks to consume more than allocated  up to a certain maximum fraction of CPU time  if this doesn’t break others’ guarantees * https://lkml.org/lkml/2016/12/30/107
  11. 11. ©ARM 201711 Bandwidth Reclaiming (cont.)  Greedy Reclamation of Unused Bandwidth (GRUB)1  3 components2  tracking of active utilization  modification of the accounting rule  multiprocessor support (original algorithm was designed for UP)  for more details you are very welcome to attend the hacking session! 1 - Greedy reclamation of unused bandwidth in constant-bandwidth servers - Giuseppe Lipari, Sanjoy K. Baruah (https://goo.gl/xl4CUk) 2 - Greedy CPU reclaiming for SCHED DEADLINE - Luca Abeni, Juri Lelli, Claudio Scordino, Luigi Palopoli (https://goo.gl/e8EC8q)
  12. 12. ©ARM 201712 Bandwidth Reclaiming (results)  Task1 (6ms, 20ms) constant execution time of 5ms  Task2 (45ms, 260ms) experiences occasional variances (35ms-52ms) CDF Response time (ms) T2’s reservation period
  13. 13. ©ARM 201713 Bandwidth Reclaiming (results)  Task1 (6ms, 20ms) constant execution time of 5ms  Task2 (45ms, 260ms) experiences occasional variances (35ms-52ms)  Cumulative Distribution Function (CDF) probability that Response time will be less or equal to x ms CDF Response time (ms) T2’s reservation period
  14. 14. ©ARM 201714 Bandwidth Reclaiming (results)  Task1 (6ms, 20ms) constant execution time of 5ms  Task2 (45ms, 260ms) experiences occasional variances (35ms-52ms)  Plain CBS T2’s response time bigger then reservation period (~25%) CDF Response time (ms) T2’s reservation period
  15. 15. ©ARM 201715 Bandwidth Reclaiming (results)  Task1 (6ms, 20ms) constant execution time of 5ms  Task2 (45ms, 260ms) experiences occasional variances (35ms-52ms)  GRUB T2 always completes before reservation period (using bandwidth left by T1) CDF Response time (ms) T2’s reservation period
  16. 16. ©ARM 201716 CHAPTER 3 Rock around the Clock (... and CPU)
  17. 17. ©ARM 201717 Agenda  Deadline scheduling (SCHED_DEADLINE)  Why is development now happening (out of the blue?)  Bandwidth reclaiming  Frequency/CPU scaling of reservation parameters  Coupling with frequency selection  Group scheduling  Future
  18. 18. ©ARM 201718 Frequency/CPU scaling  Reservation runtime needs scaling according to frequency and CPU max capacity  for frequency, use the ratio between max and current capacity to enlarge the runtime granted to a task at admission control  similarly for CPU, but using the ratio between biggest and current CPU capacity  nice example running on HiKey will be presented during the hacking session capacitycurr capacitymax runtimeoriginalruntimescaled _ _ __ 
  19. 19. ©ARM 201719 Agenda  Deadline scheduling (SCHED_DEADLINE)  Why is development now happening (out of the blue?)  Bandwidth reclaiming  Frequency/CPU scaling of reservation parameters  Coupling with frequency selection  Group scheduling  Future
  20. 20. ©ARM 201720 Driving frequency selection  scaling clock frequency, while meeting tasks’ requirements (deadlines)  scheduler driven CPU clock frequency selection  schedutil cpufreq governor SCHED_NORMAL – uses util_avg (PELT) SCHED_FIFO/RR and SCHED_DEADLINE – go to max!  once bandwidth reclaiming is in*  start using SCHED_DEADLINE’s per-CPU utilization contribution (sum to others)  move CPU frequency selection triggering points (where DL utilization changes)  allow sugov kworker thread(s) to always preempt SCHED_DEADLINE tasks (and lower priority) – for !fast_switch_enabled drivers  and again attend the hacking session for more details/results/fun * Claudio Scordino (Evidence Srl) is helping with this.
  21. 21. ©ARM 201721 CHAPTER 4 Groupies
  22. 22. ©ARM 201722 Agenda  Deadline scheduling (SCHED_DEADLINE)  Why is development now happening (out of the blue?)  Bandwidth reclaiming  Frequency/CPU scaling of reservation parameters  Coupling with frequency selection  Group scheduling  Future
  23. 23. ©ARM 201723 Group scheduling  Currently, one to one association between tasks and reservations  Sometime it might be better/easier to group a set of tasks into the same reservation  virtual machine threads  rendering pipeline  legacy application (that for example needs forking)  high priority driver kthread(s)  Hierarchical/Group scheduling1,2,3  cgroups support  temporal isolation between groups (and single entities) 1 - A Framework for Hierarchical Scheduling on Multiprocessors - Giuseppe Lipari, Enrico Bini (https://goo.gl/veKrJy) 2 - Hierarchical Multiprocessor CPU Reservations for the Linux Kernel - F. Checconi,T. Cucinotta, D. Faggioli, G. Lipari (https://goo.gl/PIJaQe) 3 - The IRMOS real-time scheduler - T. Cucinotta, F. Checconi (https://lwn.net/Articles/398470/)
  24. 24. ©ARM 201724 Group scheduling  Hierarchical means  first level is EDF  second level is RT (FIFO/RR)  Should eventually supplant RT-throttling EDF FIFO FIFO T1 T2 T3 T4
  25. 25. ©ARM 201725 Group scheduling  On multiprocessors  One DEADLINE group entity per CPU  Coexists with single DEADLINE entities T1 T2 T3 T4T5 T6 T7
  26. 26. ©ARM 201726 Group scheduling  On multiprocessors  One DEADLINE group entity per CPU  Coexists with single DEADLINE entities  Sub RT entities get migrated according to G-FP (push/pull) T1 T2 T3 T4T5 T6 T7 T5
  27. 27. ©ARM 201727 CHAPTER 5 It IS bright!
  28. 28. ©ARM 201728 Agenda  Deadline scheduling (SCHED_DEADLINE)  Why is development now happening (out of the blue?)  Bandwidth reclaiming  Frequency/CPU scaling of reservation parameters  Coupling with frequency selection  Group scheduling  Future
  29. 29. ©ARM 201729 Future  NEAR  experimenting with Android  reclaiming by demotion towards lower priority class  capacity awareness (for heterogeneous systems)  energy awareness (Energy Aware Scheduling for DEADLINE)  NEAR(...ISH)  support single CPU affinity  enhanced priority inheritance (M-BWI most probably)  dynamic feedback mechanism (adapt reservation parameters to task’ needs)
  30. 30. The trademarks featured in this presentation are registered and/or unregistered trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved. All other marks featured may be trademarks of their respective owners. Copyright © 2017 ARM Limited ©ARM 2017 Get involved! Shoot me an email <juri.lelli@arm.com> Ask questions on LKML, linux-rt-users or eas-dev Come join us @ OSPM-summit (https://goo.gl/ngTcgB) ... maybe remotely :-) And don’t forget to collect your prizes!!!

×