tools/perf/pmu-events/arch/x86/amdzen3/memory.json
Source file repositories/reference/linux-study-clean/tools/perf/pmu-events/arch/x86/amdzen3/memory.json
File Facts
- System
- Linux kernel
- Corpus path
tools/perf/pmu-events/arch/x86/amdzen3/memory.json- Extension
.json- Size
- 15919 bytes
- Lines
- 429
- Domain
- Support Tooling And Documentation
- Bucket
- tools
- Inferred role
- Support Tooling And Documentation: configuration, schema, or hardware description
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
[
{
"EventName": "ls_bad_status2.stli_other",
"EventCode": "0x24",
"BriefDescription": "Non-forwardable conflict; used to reduce STLI's via software. All reasons. Store To Load Interlock (STLI) are loads that were unable to complete because of a possible match with an older store, and the older store could not do STLF for some reason.",
"PublicDescription" : "Store-to-load conflicts: A load was unable to complete due to a non-forwardable conflict with an older store. Most commonly, a load's address range partially but not completely overlaps with an uncompleted older store. Software can avoid this problem by using same-size and same-alignment loads and stores when accessing the same data. Vector/SIMD code is particularly susceptible to this problem; software should construct wide vector stores by manipulating vector elements in registers using shuffle/blend/swap instructions prior to storing to memory, instead of using narrow element-by-element stores.",
"UMask": "0x02"
},
{
"EventName": "ls_locks.spec_lock_hi_spec",
"EventCode": "0x25",
"BriefDescription": "Retired lock instructions. High speculative cacheable lock speculation succeeded.",
"UMask": "0x08"
},
{
"EventName": "ls_locks.spec_lock_lo_spec",
"EventCode": "0x25",
"BriefDescription": "Retired lock instructions. Low speculative cacheable lock speculation succeeded.",
"UMask": "0x04"
},
{
"EventName": "ls_locks.non_spec_lock",
"EventCode": "0x25",
"BriefDescription": "Retired lock instructions. Non-speculative lock succeeded.",
"UMask": "0x02"
},
{
"EventName": "ls_locks.bus_lock",
"EventCode": "0x25",
"BriefDescription": "Retired lock instructions. Comparable to legacy bus lock.",
"UMask": "0x01"
},
{
"EventName": "ls_ret_cl_flush",
"EventCode": "0x26",
"BriefDescription": "The number of retired CLFLUSH instructions. This is a non-speculative event."
},
{
"EventName": "ls_ret_cpuid",
"EventCode": "0x27",
"BriefDescription": "The number of CPUID instructions retired."
},
{
"EventName": "ls_dispatch.ld_st_dispatch",
"EventCode": "0x29",
"BriefDescription": "Load-op-Store Dispatch. Dispatch of a single op that performs a load from and store to the same memory address. Counts the number of operations dispatched to the LS unit. Unit Masks ADDed.",
"UMask": "0x04"
},
{
"EventName": "ls_dispatch.store_dispatch",
"EventCode": "0x29",
"BriefDescription": "Dispatch of a single op that performs a memory store. Counts the number of operations dispatched to the LS unit. Unit Masks ADDed.",
"UMask": "0x02"
},
{
"EventName": "ls_dispatch.ld_dispatch",
"EventCode": "0x29",
"BriefDescription": "Dispatch of a single op that performs a memory load. Counts the number of operations dispatched to the LS unit. Unit Masks ADDed.",
"UMask": "0x01"
},
{
"EventName": "ls_smi_rx",
"EventCode": "0x2b",
"BriefDescription": "Counts the number of SMIs received."
},
{
"EventName": "ls_int_taken",
"EventCode": "0x2c",
"BriefDescription": "Counts the number of interrupts taken."
},
Annotation
- Atlas domain: Support Tooling And Documentation / tools.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.