1========================= 2Hardware Latency Detector 3========================= 4 5Introduction 6------------- 7 8The tracer hwlat_detector is a special purpose tracer that is used to 9detect large system latencies induced by the behavior of certain underlying 10hardware or firmware, independent of Linux itself. The code was developed 11originally to detect SMIs (System Management Interrupts) on x86 systems, 12however there is nothing x86 specific about this patchset. It was 13originally written for use by the "RT" patch since the Real Time 14kernel is highly latency sensitive. 15 16SMIs are not serviced by the Linux kernel, which means that it does not 17even know that they are occurring. SMIs are instead set up by BIOS code 18and are serviced by BIOS code, usually for "critical" events such as 19management of thermal sensors and fans. Sometimes though, SMIs are used for 20other tasks and those tasks can spend an inordinate amount of time in the 21handler (sometimes measured in milliseconds). Obviously this is a problem if 22you are trying to keep event service latencies down in the microsecond range. 23 24The hardware latency detector works by hogging one of the cpus for configurable 25amounts of time (with interrupts disabled), polling the CPU Time Stamp Counter 26for some period, then looking for gaps in the TSC data. Any gap indicates a 27time when the polling was interrupted and since the interrupts are disabled, 28the only thing that could do that would be an SMI or other hardware hiccup 29(or an NMI, but those can be tracked). 30 31Note that the hwlat detector should *NEVER* be used in a production environment. 32It is intended to be run manually to determine if the hardware platform has a 33problem with long system firmware service routines. 34 35Usage 36------ 37 38Write the ASCII text "hwlat" into the current_tracer file of the tracing system 39(mounted at /sys/kernel/tracing or /sys/kernel/tracing). It is possible to 40redefine the threshold in microseconds (us) above which latency spikes will 41be taken into account. 42 43Example:: 44 45 # echo hwlat > /sys/kernel/tracing/current_tracer 46 # echo 100 > /sys/kernel/tracing/tracing_thresh 47 48The /sys/kernel/tracing/hwlat_detector interface contains the following files: 49 50 - width - time period to sample with CPUs held (usecs) 51 must be less than the total window size (enforced) 52 - window - total period of sampling, width being inside (usecs) 53 54By default the width is set to 500,000 and window to 1,000,000, meaning that 55for every 1,000,000 usecs (1s) the hwlat detector will spin for 500,000 usecs 56(0.5s). If tracing_thresh contains zero when hwlat tracer is enabled, it will 57change to a default of 10 usecs. If any latencies that exceed the threshold is 58observed then the data will be written to the tracing ring buffer. 59 60The minimum sleep time between periods is 1 millisecond. Even if width 61is less than 1 millisecond apart from window, to allow the system to not 62be totally starved. 63 64If tracing_thresh was zero when hwlat detector was started, it will be set 65back to zero if another tracer is loaded. Note, the last value in 66tracing_thresh that hwlat detector had will be saved and this value will 67be restored in tracing_thresh if it is still zero when hwlat detector is 68started again. 69 70The following tracing directory files are used by the hwlat_detector: 71 72in /sys/kernel/tracing: 73 74 - tracing_threshold - minimum latency value to be considered (usecs) 75 - tracing_max_latency - maximum hardware latency actually observed (usecs) 76 - tracing_cpumask - the CPUs to move the hwlat thread across 77 - hwlat_detector/width - specified amount of time to spin within window (usecs) 78 - hwlat_detector/window - amount of time between (width) runs (usecs) 79 - hwlat_detector/mode - the thread mode 80 81By default, one hwlat detector's kernel thread will migrate across each CPU 82specified in cpumask at the beginning of a new window, in a round-robin 83fashion. This behavior can be changed by changing the thread mode, 84the available options are: 85 86 - none: do not force migration 87 - round-robin: migrate across each CPU specified in cpumask [default] 88 - per-cpu: create one thread for each cpu in tracing_cpumask 89