mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-20 03:30:59 -04:00
| Filename | Latest commit message | Latest commit date |
|---|---|---|
93c29d1397
Some workloads doing memory access might appear memory latency bound even though they might not actually be memory latency bound. This error can happen when the core that's running the workload is very parallelized or can do out of order executions, etc so not all memory accesses would actually stall the core. This can also happen when the the memory access monitoring capabilities aren't ideal and end up counting more kinds of memory accesses than what would be ideal. In this case, the IPM ratio can be lower than what it would be if we had ideal monitoring capabilities. To account for these errors, if the core has a stall cycle counting capabilities, check for a minimum stall% before the workload is considered memory latency bound. This would help reduce the inaccuracies, but is not a replacement for IPM ratio scheme because the stall% method doesn't allow us to detect which level of memory the workload is latency bound on, but the IPM ratio does (based on which memory accesses we use for calculating the ratio). Change-Id: I4363d7848584e5562f6683b5ad6b0f99017ec71b Signed-off-by: Saravana Kannan <skannan@codeaurora.org> [avajid@codeaurora.org: resolved minor merge conflicts and made minor styling changes] Signed-off-by: Amir Vajid <avajid@codeaurora.org> |
||
| .. | ||
| acpi | ||
| asm-generic | ||
| clocksource | ||
| crypto | ||
| drm | ||
| dt-bindings | ||
| keys | ||
| kvm | ||
| linux | ||
| math-emu | ||
| media | ||
| misc | ||
| net | ||
| pcmcia | ||
| ras | ||
| rdma | ||
| scsi | ||
| soc | ||
| sound | ||
| target | ||
| trace | ||
| uapi | ||
| vdso | ||
| video | ||
| xen | ||
| Kbuild | ||