@@ -347,81 +347,8 @@ for tickless systems. It follows the same basic strategy as the ``menu`` `one
347
347
<menu-gov_> `_: it always tries to find the deepest idle state suitable for the
348
348
given conditions. However, it applies a different approach to that problem.
349
349
350
- First, it does not use sleep length correction factors, but instead it attempts
351
- to correlate the observed idle duration values with the available idle states
352
- and use that information to pick up the idle state that is most likely to
353
- "match" the upcoming CPU idle interval. Second, it does not take the tasks
354
- that were running on the given CPU in the past and are waiting on some I/O
355
- operations to complete now at all (there is no guarantee that they will run on
356
- the same CPU when they become runnable again) and the pattern detection code in
357
- it avoids taking timer wakeups into account. It also only uses idle duration
358
- values less than the current time till the closest timer (with the scheduler
359
- tick excluded) for that purpose.
360
-
361
- Like in the ``menu `` governor `case <menu-gov _>`_, the first step is to obtain
362
- the *sleep length *, which is the time until the closest timer event with the
363
- assumption that the scheduler tick will be stopped (that also is the upper bound
364
- on the time until the next CPU wakeup). That value is then used to preselect an
365
- idle state on the basis of three metrics maintained for each idle state provided
366
- by the ``CPUIdle `` driver: ``hits ``, ``misses `` and ``early_hits ``.
367
-
368
- The ``hits `` and ``misses `` metrics measure the likelihood that a given idle
369
- state will "match" the observed (post-wakeup) idle duration if it "matches" the
370
- sleep length. They both are subject to decay (after a CPU wakeup) every time
371
- the target residency of the idle state corresponding to them is less than or
372
- equal to the sleep length and the target residency of the next idle state is
373
- greater than the sleep length (that is, when the idle state corresponding to
374
- them "matches" the sleep length). The ``hits `` metric is increased if the
375
- former condition is satisfied and the target residency of the given idle state
376
- is less than or equal to the observed idle duration and the target residency of
377
- the next idle state is greater than the observed idle duration at the same time
378
- (that is, it is increased when the given idle state "matches" both the sleep
379
- length and the observed idle duration). In turn, the ``misses `` metric is
380
- increased when the given idle state "matches" the sleep length only and the
381
- observed idle duration is too short for its target residency.
382
-
383
- The ``early_hits `` metric measures the likelihood that a given idle state will
384
- "match" the observed (post-wakeup) idle duration if it does not "match" the
385
- sleep length. It is subject to decay on every CPU wakeup and it is increased
386
- when the idle state corresponding to it "matches" the observed (post-wakeup)
387
- idle duration and the target residency of the next idle state is less than or
388
- equal to the sleep length (i.e. the idle state "matching" the sleep length is
389
- deeper than the given one).
390
-
391
- The governor walks the list of idle states provided by the ``CPUIdle `` driver
392
- and finds the last (deepest) one with the target residency less than or equal
393
- to the sleep length. Then, the ``hits `` and ``misses `` metrics of that idle
394
- state are compared with each other and it is preselected if the ``hits `` one is
395
- greater (which means that that idle state is likely to "match" the observed idle
396
- duration after CPU wakeup). If the ``misses `` one is greater, the governor
397
- preselects the shallower idle state with the maximum ``early_hits `` metric
398
- (or if there are multiple shallower idle states with equal ``early_hits ``
399
- metric which also is the maximum, the shallowest of them will be preselected).
400
- [If there is a wakeup latency constraint coming from the `PM QoS framework
401
- <cpu-pm-qos_> `_ which is hit before reaching the deepest idle state with the
402
- target residency within the sleep length, the deepest idle state with the exit
403
- latency within the constraint is preselected without consulting the ``hits ``,
404
- ``misses `` and ``early_hits `` metrics.]
405
-
406
- Next, the governor takes several idle duration values observed most recently
407
- into consideration and if at least a half of them are greater than or equal to
408
- the target residency of the preselected idle state, that idle state becomes the
409
- final candidate to ask for. Otherwise, the average of the most recent idle
410
- duration values below the target residency of the preselected idle state is
411
- computed and the governor walks the idle states shallower than the preselected
412
- one and finds the deepest of them with the target residency within that average.
413
- That idle state is then taken as the final candidate to ask for.
414
-
415
- Still, at this point the governor may need to refine the idle state selection if
416
- it has not decided to `stop the scheduler tick <idle-cpus-and-tick _>`_. That
417
- generally happens if the target residency of the idle state selected so far is
418
- less than the tick period and the tick has not been stopped already (in a
419
- previous iteration of the idle loop). Then, like in the ``menu `` governor
420
- `case <menu-gov _>`_, the sleep length used in the previous computations may not
421
- reflect the real time until the closest timer event and if it really is greater
422
- than that time, a shallower state with a suitable target residency may need to
423
- be selected.
424
-
350
+ .. kernel-doc :: drivers/cpuidle/governors/teo.c
351
+ :doc: teo-description
425
352
426
353
.. _idle-states-representation :
427
354
0 commit comments