Lines Matching refs:latency
23 There's latency tracing to examine what occurs between interrupts
130 Some of the tracers record the max latency.
135 latency is greater than the value in this
140 Some latency tracers will record a trace whenever the
141 latency is greater than the number in this file.
503 the trace with the longest max latency.
506 trace with the latency-format option enabled.
521 Traces and records the max latency that it takes for
528 Traces and records the max latency that it takes for just
583 PID "1977", the CPU that it was running on "000", the latency format
592 When the latency-format option is enabled or when one of the latency
594 why a latency happened. Here is a typical trace.
598 # irqsoff latency trace v1.1.5 on 3.8.0-test+
600 # latency: 259 us, #4/4, CPU#2 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
635 (3.10). Then it displays the max latency in microseconds (259 us). The number
640 The task is the process that was running when the latency
679 time: When the latency-format option is enabled, the trace file
681 trace. This differs from the output when latency-format
696 Note, the latency tracers will usually end with a back trace
697 to easily find where the latency occurred.
724 latency-format
770 latency-format option is enabled.
836 latency-format - This option changes the trace. When
888 function-trace - The latency tracers will enable function tracing
890 it is disabled, the latency tracers do not trace
892 when performing latency tests.
905 the kernel know of a new mouse event. The result is a latency
909 disabled. When a new maximum latency is hit, the tracer saves
910 the trace leading up to that latency point so that every time a
927 # irqsoff latency trace v1.1.5 on 3.8.0-test+
929 # latency: 16 us, #4/4, CPU#0 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
964 Here we see that that we had a latency of 16 microseconds (which is
968 between the time of recording the max latency and the time of
969 recording the function that had that latency.
978 # irqsoff latency trace v1.1.5 on 3.8.0-test+
980 # latency: 71 us, #168/168, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
1043 Here we traced a 71 microsecond latency. But we also see all the
1046 overhead may extend the latency times. But nevertheless, this
1059 Like the irqsoff tracer, it records the maximum latency for
1073 # preemptoff latency trace v1.1.5 on 3.8.0-test+
1075 # latency: 46 us, #4/4, CPU#1 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
1110 # preemptoff latency trace v1.1.5 on 3.8.0-test+
1112 # latency: 83 us, #241/241, CPU#1 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
1223 # preemptirqsoff latency trace v1.1.5 on 3.8.0-test+
1225 # latency: 100 us, #4/4, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
1276 # preemptirqsoff latency trace v1.1.5 on 3.8.0-test+
1278 # latency: 161 us, #339/339, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
1392 # wakeup latency trace v1.1.5 on 3.8.0-test+
1394 # latency: 15 us, #4/4, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
1427 latency". I stress the point that this is about RT tasks. It is
1428 also important to know the scheduling latency of non-RT tasks,
1429 but the average schedule latency is better for non-RT tasks.
1433 Real-Time environments are interested in the worst case latency.
1434 That is the longest latency it takes for something to happen,
1436 only have a large latency once in a while, but that would not
1441 worst case latency of RT tasks (just run the normal wakeup
1460 # wakeup_rt latency trace v1.1.5 on 3.8.0-test+
1462 # latency: 5 us, #4/4, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
1507 # wakeup_rt latency trace v1.1.5 on 3.8.0-test+
1509 # latency: 29 us, #85/85, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
1617 As function tracing can induce a much larger latency, but without
1618 seeing what happens within the latency it is hard to know what
1632 # wakeup_rt latency trace v1.1.5 on 3.8.0-test+
1634 # latency: 6 us, #12/12, CPU#2 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
2582 available to all non latency tracers. (Latency tracers which
2583 record max latency, such as "irqsoff" or "wakeup", can't use
2654 one of the latency tracers, you will get the following results.