General overhaul of events and spec text #18
Conversation
…e files from the repo
* Add flexibility to cache levels and types * Call out option to add custom caches * Discuss shared caches, and counting only for the given hart * Revise set of access type subevents * Remove OPREF sub-events. No need for UNUSED given that RV doesn't have SW prefetches. * Event tables in CACHE chapter are an example configuration
… events and renaming .HIT events
|
Perhaps unwisely, this PR now also includes major revisions to instruction counting events, nesting them all under INST.* events. |
|
Here's a pdf of the spec including this PR as it stands. |
…ts to include all widths
… improvements to match events
…-side TLB metrics
…remove table headers.
…escriptions of L2+ events, improve text
|
Here's the latest and greatest draft spec incorporating this PR. |
There was a problem hiding this comment.
Here are some comments based on the pdf dated 2025-01-22
- In 2.1.1. I didn't see a way to distinguish conditional vs unconditional branches. I think this would be good to have for
beq, bneetc. - Table 10 Inst Metrics would need to be updated for conditional branches too.
- In 2.1.1. I'm not sure how much value
inferrablevsuninferrableprovides in addition todirect andindirect`. Is there something more implied here? - In 2.1.2 (page 8) -- "even non-speculative (.RET) DRSC events" --> DSRC?
- In 2.1.2 (page 8) -- Table 6. ASRC Event Translation Sources -- s/standars/standards/
- In 2.3 s/idenfies/indentifies/
- In Table 13. CACHE Event Access or Operation Type -- I wonder if "outer cache" implies off-chip? If so we should just mention that instead.
- Why shouldn't OPREF not increment if a cache is shared by multiple harts? Does this mean that we wouldn't count OPREF for an LLC?
- In Table 22, s/oustanding/outstanding/
- In Table 26, s/selcted/selected/ and s/standars/standards
Haven't looked at the TMA section yet..
In RISC-V parlance, a "branch" is a conditional jump. So INST.BRANCH.RET counts retired conditional branches. But you're right that there's no single event to count all unconditional jumps. Ideally these would be implemented as "combination" events, where some event selector bits correspond to each transfer type, and combinations can be chosen. But I'd prefer not to require that, so we should probably specify any combinations that are interesting. I did that with TK and PRED, for instance. I can add unconditional. Wonder if we want some combination of RETURN and CORSWAP (which is a return + call)? Or CALL and CORSWAP?
Spoiler alert: I'm going to propose that we drop standardizing metrics, and stick to events. There might be an exception for topdown.
The trace spec uses inferrable/uninferrable. I think most are more accustomed to direct/indirect, but I included the other words to make sure everyone knows we're talking about the same thing.
Thanks, will fix those.
I just meant a cache that can fill into this one. E.g., to the L2, the L3 is an outer cache, but the L1 is not. I made up the term though, maybe not the best one.
Since these are hart events, I'm assuming they should only be able to count events directly related to the hart. For a shared (external) LLC, I'd assume it would have its own PMU that could count accesses/misses/etc regardless of hart. So I assume that's where LLC prefetches would be counted, not in the hart.
Thanks.
|
|
@snehasish please see my latest commits that reference issue #18, which I believe address your feedback. And yes, I later realized there is no issue #18, the feedback was given as a comment in PR #18. :) |
|
Changes look good to me. How about merging this so that future changes will have smaller diffs to review? |
|
That's the plan, will do so now. |
No description provided.