summaryrefslogtreecommitdiffstats
path: root/src/plugins/perfmon/perfmon.h
AgeCommit message (Collapse)AuthorFilesLines
2019-03-20perfmon: python to C parser for intel CPUsDamjan Marion1-9/+8
EXAMPLE: src/plugins/perfmon/intel_json_to_c.py \ -i skylakex_core_v1.12.json \ -o src/plugins/perfmon/perfmon_intel_skx.c \ -m 0x55,0 \ -m 0x55,1 \ -m 0x55,2 \ -m 0x55,3 Change-Id: I16ce059e231d340ecfcb6f6638e29c5b46304683 Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-01-27perfmon: collect data on selected thread(s)Dave Barach1-0/+3
Add missing pre-input node runtime fork and refork code. unix-epoll-input runs on all threads; each instance needs its own runtime stats. Change-Id: I16b02e42d0c95f863161176c4bb9f9917bef809d Signed-off-by: Dave Barach <dave@barachs.net>
2019-01-24perfmon plugin: 2-way parallel stat collectionDave Barach1-5/+9
As a FUD reduction measure, this patch implements 2-way parallel counter collection. Synthetic stat component counter pairs run at the same time. Running two counters (of any kind) at the same time naturally reduces the aggregate time required by an approximate factor-of-2, depending on whether an even or odd number of stats have been requested. I don't completely buy the argument that computing synthetic stats such as instructions-per-clock will be inaccurate if component counter values are collected sequentially. Given uniform traffic pattern, it must make no difference. As the collection interval increases, the difference between serial and parallel component counter collection will approach zero, see also the Central Limit theorem. Change-Id: I36ebdcf125e8882cca8a1929ec58f17fba1ad8f1 Signed-off-by: Dave Barach <dave@barachs.net>
2018-10-22X86_64 perf counter pluginDave Barach1-0/+145
Change-Id: Ie5a00c15ee9536cc61afab57f6cadc1aa1972f3c Signed-off-by: Dave Barach <dave@barachs.net>