Scribd Logo
Upload

Welcome to Scribd!

  • 27 views

    System and Devices Latency On Linux

    Uploaded by

    wanna_ac
    This document proposes a new model for managing system and device latency on embedded Linux systems. The current model has several problems, including a lack of concept of overall latency and no interdependency between power management frameworks. The new model breaks down overall latency into software, system-on-chip hardware, and external hardware components. It aims to reduce latency measurements into independent factors, calculate worst-case latency for devices and power domains dynamically, and implement self-measurement of device latency in a generic way. The changes would help integrate latency management across frameworks and account for dynamic system settings.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF, TXT or read online from Scribd

    System and Devices Latency On Linux

    Uploaded by

    wanna_ac
    27 views30 pages
    This document proposes a new model for managing system and device latency on embedded Linux systems. The current model has several problems, including a lack of concept of overall latency and no interdependency between power management frameworks. The new model breaks down overall latency into software, system-on-chip hardware, and external hardware components. It aims to reduce latency measurements into independent factors, calculate worst-case latency for devices and power domains dynamically, and implement self-measurement of device latency in a generic way. The changes would help integrate latency management across frameworks and account for dynamic system settings.

    Original Description:

    A New Model for the System and Devices Latency on Linux

    Original Title

    System and Devices Latency on Linux

    Copyright

    © Attribution Non-Commercial (BY-NC)

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    This document proposes a new model for managing system and device latency on embedded Linux systems. The current model has several problems, including a lack of concept of overall latency and no interdependency between power management frameworks. The new model breaks down overall latency into software, system-on-chip hardware, and external hardware components. It aims to reduce latency measurements into independent factors, calculate worst-case latency for devices and power domains dynamically, and implement self-measurement of device latency in a generic way. The changes would help integrate latency management across frameworks and account for dynamic system settings.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    27 views30 pages

    System and Devices Latency On Linux

    Uploaded by

    wanna_ac
    This document proposes a new model for managing system and device latency on embedded Linux systems. The current model has several problems, including a lack of concept of overall latency and no interdependency between power management frameworks. The new model breaks down overall latency into software, system-on-chip hardware, and external hardware components. It aims to reduce latency measurements into independent factors, calculate worst-case latency for devices and power domains dynamically, and implement self-measurement of device latency in a generic way. The changes would help integrate latency management across frameworks and account for dynamic system settings.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    You are on page 1of 30

    Making Wireless

    System Engineering Linux Development Center

    Fosdem - ELC 2012


    A new model for the system and devices latency

    Jean Pihet <j-pihet@ti.com>


    17 Feb 2012 v1.2

    Making Wireless

    Introduction
    Background
    What is the 'latency' ?

    System Engineering Linux Development Center

    There is some overhead when a part of the system goes to a low power mode in idle, both at suspend and resume times. The allowed latency needs to be taken into account when deciding the next low power state. 'A part of the system' = SW, HW SoC, HW external.

    How to specify the allowed latency ?


    The PM QoS framework allows the kernel and user to specify the allowed latency. The framework calculates the aggregated constraint value and calls the registered platform-specific handlers in order to apply the constraints at lower level. Cf. Documentation/power/pm_qos_interface.txt for the available classes: PM QoS classes for cpu_dma_latency, network_latency, network_throughput. The per-device PM QoS framework provides the API to manage the per-device latency constraints.
    2

    ELC 2012 A new model for system and devices latency

    Making Wireless

    Introduction
    Background
    What is the point of controlling the latency ?

    System Engineering Linux Development Center

    The point is to dynamically optimize the power consumption of all system components. Knowing the allowed latency (from the constraints) and the expected worst-case latency allows to choose the optimum power state.

    ELC 2012 A new model for system and devices latency

    Making Wireless

    Introduction
    Terminology

    System Engineering Linux Development Center

    Latency : time to react to an external event, e.g. time spent to execute the handler code after an IRQ, time spent to execute driver code from an external wake-up event. HW latency : latency introduced by the HW to transition between power states. SW latency : time for the SW to execute low power transition code, e.g. IP block save & restore, caches flush/invalidate etc. System : 'everything needed to execute the kernel code', e.g. on OMAP3, system = CPU0 + CORE (main memory, caches, IRQ controller...). Per-device latency : latency of a device (or peripheral). The per-device PM QoS framework allows to control the devices states from the allowed devices latency. Cpuidle : framework that controls the CPUs low power states (=C-states), from the allowed system latency. Note : Is being abused to control the system state. PM runtime : framework that allows the dynamic switching of resources. 4

    ELC 2012 A new model for system and devices latency

    Making Wireless

    Introduction
    OMAP SoC PM
    Dynamic and hierarchical PM

    System Engineering Linux Development Center

    Clock->Pwrdm->Voltdm->External Voltage Regulators Clock->DPLL->External Oscillators

    The HW latency depends on system settings

    The behavior of the voltage regulators and external oscillators depends on various system settings. The system settings can be dynamically controlled. E.g. OMAP <-> PMIC signals : SYS_CLKREQ, SYS_OFFMODE.

    ELC 2012 A new model for system and devices latency

    Making Wireless
    System Engineering Linux Development Center

    Source : OMAP3430 TRM, public version


    6

    ELC 2012 A new model for system and devices latency

    Making Wireless
    System Engineering Linux Development Center

    Source : TWL4030 Power Scripts [2]


    7

    ELC 2012 A new model for system and devices latency

    Making Wireless

    Current model

    System Engineering Linux Development Center

    ELC 2012 A new model for system and devices latency

    Making Wireless

    Current model : latency figures


    cpuidle latency figures

    System Engineering Linux Development Center

    From [1] : measuring the timing and the current consumption (thanks to the TI PSI team!) leads to the following graph of the energy spent vs time :

    ELC 2012 A new model for system and devices latency

    Making Wireless

    Current model : latency figures


    cpuidle latency figures (cont'd)
    Derive some usable figures from the measurements :

    System Engineering Linux Development Center

    Identify the energy-wise interesting C-states and threshold values (C1, C3, C5, C9) Aggregate the timings results. From the various sources of data the following figures are derived for all C-states (timings in us).

    Notes: produce the actual figures (to be used in the code) involves a lot of operations : interpolation, intersection (linear algebra) etc. 10

    ELC 2012 A new model for system and devices latency

    Making Wireless

    Current model : latency figures


    Inject the figures into the cpuidle framework :

    System Engineering Linux Development Center

    11

    ELC 2012 A new model for system and devices latency

    Making Wireless

    Current model : latency figures


    Power domains latency figures
    From [1] :

    System Engineering Linux Development Center

    Since cpuidle only manages the MPU and CORE the wake-up latency values for the other power domains must be measured separately, by adjusting the target states of the power domains (in /debug/pm_debug/xxxx_pwrdm/suspend). The significative power domains latencies are derived from the measurements as follows:

    Notes: sys_clkreq and sys_offmode are not supported

    12

    ELC 2012 A new model for system and devices latency

    Making Wireless

    Current model : latency figures


    Inject the figures into the powercpuidle framework :

    System Engineering Linux Development Center

    13

    ELC 2012 A new model for system and devices latency

    Making Wireless

    Current model

    System Engineering Linux Development Center

    14

    ELC 2012 A new model for system and devices latency

    Making Wireless

    Problems
    There is no concept of 'overall latency'. No interdependency between PM frameworks

    System Engineering Linux Development Center

    Ex. on OMAP3 : cpuidle manages only a subset of the power domains (MPU, CORE). Ex. on OMAP3 per-device PM QoS manages the other power domains. No relation between the frameworks, each framework has its own latency numbers.

    Some system settings are not included in the model

    Mainly because of the (lack of) SW support at the time of the measurement session. Ex. On OMAP3 : voltage scaling in low power modes, sys_clkreq, sys_offmode and the interaction with the PowerIC.

    Dynamic nature of the system settings

    The measured numbers are for a fixed setup, with predefined system settings. The measured numbers are constant.

    15

    ELC 2012 A new model for system and devices latency

    Making Wireless

    Problems (more of them!)

    System Engineering Linux Development Center

    Self-measuremente of OMAP devices (de)activate : Great idea, but ...

    The code is not generic enough, only the omap_device code has the feature implemented. The self-measurement results are not used at all (excepted to issue a 'New worst case (de)activate latency' debug message).

    Measuring the various latencies is difficult

    The measurement procedure needs to be re-run for every different HW (or possibly SW) setup. Measuring the latency of all power domains is difficult : take measurements, derive energy graphs, calculate intersections, adapt to missing key parameters etc.

    16

    ELC 2012 A new model for system and devices latency

    Making Wireless

    Solution proposal
    Overall latency calculation

    System Engineering Linux Development Center

    We need a model which breaks down the overall latency into the latencies from every contributor :

    latency = latencySW + latencyHW latency = latencySW + latencySoC + latencyExternal HW

    latencySW = time for the SW to save/restore the context of an IP block

    latencySoC = time for the SoC HW to change an IP block state. Includes the Power Domain state transition, DPLL stop/relock etc.

    latencyExternal HW = time to stop/restart the external HW. Ex : external crystal oscillator, external power supply etc.

    Note : every latency factor might be divided into smaller factors. E.g. : On OMAP a DPLL can feed multiple power domains. 17
    ELC 2012 A new model for system and devices latency

    Making Wireless

    New model

    System Engineering Linux Development Center

    18

    ELC 2012 A new model for system and devices latency

    Making Wireless

    Impact on the current code


    Reduce the measurement results into factors

    System Engineering Linux Development Center

    From the model, derive the independent factors for the overall latency. Differentiate the fixed factors from the variable ones (i.e. At HW level a power domain transition worst-case latency is fixed).

    Pass the latency data along with board-specific data


    From the board files. From (DT) Device Tree data.

    Note : Which data to pass from board files or DT ? Cf. Discussions on l-a-k & l-o MLs.

    Introduce functions to calculate the devices and power domains worst case latency
    Clean-up of the code that directly touches the HW settings which have an impact on the overall latency. When a HW setting is touched, re-calculate the overall worst case latency.

    19

    ELC 2012 A new model for system and devices latency

    Making Wireless

    Impact on the current code

    System Engineering Linux Development Center

    Self-measuremente of devices (de)activate worst case latency


    Ideally: Implement the self-measurement in a generic way in devices runtime PM : in generic power domain code or in devices get/put functions. Real world: 1. OMAP has its own implementation of clock/power/voltage domains 2. The generic power domain code has no provision for multiple power states, which OMAP is using (ON, INACTIVE, CSWR, OSWR, OFF), which prevents OMAP code for using it (for now). Question: How to integrate the full solution ?

    20

    ELC 2012 A new model for system and devices latency

    Making Wireless

    Impact on the current code


    Question: How to integrate the full solution ? => Implement the features in logical steps:

    System Engineering Linux Development Center

    Self-measuremente of devices (de)activate worst case latency

    1. provide a reference implementation using the OMAP code, 2. bring the concept of multiple power domains states in the generic framework, 3. change OMAP code to use the generic power domains, 4. repeat 2-3 for clocks (hint : common clock framework) and voltages, 5. port the self-measurement feature in generic code (runtime PM)

    21

    ELC 2012 A new model for system and devices latency

    Making Wireless

    Impact on the current code

    System Engineering Linux Development Center

    Self-measuremente of devices (de)activate worst case latency


    Notes: 1. (De)activate a device can cover the overall latency by propagation through the clock/power/voltage domains. So use the clock, power and voltage domains and DPLLs use count field to differentiate the measurement of the device-only latency from the other factors, 2. The use count field needs to be accessible to runtime PM from the generic clock/power/voltage domains frameworks.

    22

    ELC 2012 A new model for system and devices latency

    Making Wireless

    Next steps

    System Engineering Linux Development Center

    Start the discussions with the maintainers (here and on MLs)


    lkml, linux-pm linux-arm(-kernel), linux-omap Points to discuss : . Generic clock/power/voltage domains implementation vs OMAP specific code . Proper use of the use count field to identify the device-only latency from the propagated latency . Identify the impact on the PM runtime latency measurement code . (OMAP) What are the independent factors ? What are the settings which have an impact on the latency ? . (OMAP) How to pass the SoC and board specific data (board file, DT) ?

    Write and submit code (!)


    ELC 2012 A new model for system and devices latency

    23

    Making Wireless

    Links
    Omappedia wiki
    PM debug & profiling

    System Engineering Linux Development Center

    http://www.omappedia.org/wiki/Power_Management_Debug_and_Profiling

    [1] PM devices latency measurements


    http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement

    [2] TWL4030 Power Scripts


    http://omappedia.org/wiki/TWL4030_power_scripts

    Submitted patches and discussions on MLs


    OMAP specific patches for per-device latency
    http://www.spinics.net/lists/linux-omap/msg61692.html

    The slides for this presentation


    are posted at [1]
    24

    ELC 2012 A new model for system and devices latency

    Making Wireless
    System Engineering Linux Development Center

    Thank you ! Questions ?

    25

    ELC 2012 A new model for system and devices latency

    Making Wireless
    System Engineering Linux Development Center

    26

    ELC 2012 A new model for system and devices latency

    Making Wireless
    System Engineering Linux Development Center

    Back-up slides

    27

    ELC 2012 A new model for system and devices latency

    Making Wireless

    Current model : latency figures


    cpuidle latency figures

    System Engineering Linux Development Center

    From [1] : measuring the timing and the current consumption (thanks to the TI PSI team!) leads to the following graph of the energy spent vs time :

    28

    ELC 2012 A new model for system and devices latency

    Making Wireless

    Current model : latency figures


    cpuidle latency figures (cont'd)

    System Engineering Linux Development Center

    Taking the minimum energy from the graph allows to identify the 4 energy-wise interesting C-states: C1, C3, C5, C9 and the threshold time for those C-states to be efficient. Aggregated timings results From the various sources of data the following figures are derived for all C-states (timings in us).

    Notes: The power efficient C-states are identifed as C1, C3, C5, C7 (1) When not measured, the threshold value equals to the next power efficient C-state (2) The threshold value is derived using the intersection of C3 and C4 in the graph (3) No sys_clkoff is supported, this value need to be corrected (4) Addition of HW and SW parts, using [2] (5) The threshold value calculation is the intersection of the lines in the graph, using linear algebra
    29

    ELC 2012 A new model for system and devices latency

    Making Wireless

    Current model : latency figures


    Inject the figures into the cpuidle framework :

    System Engineering Linux Development Center

    30

    ELC 2012 A new model for system and devices latency

    You might also like