Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

recipes: Heterogeneous performance harts #114

Merged
merged 1 commit into from
Apr 3, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion brs.bib
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,10 @@ @electronic{DT
title = {DeviceTree},
url = {https://www.devicetree.org/}
}
@electronic{RSPS,
title = {RISC-V Server Platform Specification},
url = {https://github.com/riscv-non-isa/riscv-server-platform}
}
@electronic{SBI,
title = {RISC-V Supervisor Binary Interface Specification},
url = {https://github.com/riscv-non-isa/riscv-sbi-doc}
Expand Down Expand Up @@ -91,4 +95,4 @@ @electronic{PerfAnalysis
title = {SIG: Performance Analysis},
url = {https://lists.riscv.org/g/sig-perf-analysis},
year = {2024}
}
}
21 changes: 4 additions & 17 deletions non-normative/recipes.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -13,20 +13,7 @@ management might not work out of the box. You could subsequently load
the right drivers from the media coming with the board or fetch newest
ones using a well-supported network adapter.

Heterogeneous performance harts (e.g. mix of "performance" and "efficiency"
harts) is a great example of a feature outside the current scope of BRS-I,
yet with potential for adverse effects to a generic operating system
written against the BRS-I spec. Such a feature does not have a standard
way of being detected by an OS, leading to scheduling anomalies in
operating systems that are not specially adapted. Consider two identical
threads that, unbeknownst to the OS, get scheduled on harts with different
performance characteristics. This might see dramatic difference in forward
progress being made, with unexpected delays, timeouts or even crashes
posible. Worse, there could be little to no system messages pointing to
the cause of such behavior. Thus, such a feature would need to be made
*opt-in* for BRS-I compliance. This could be done implicitly via loading
of system-specific drivers, or explicitly via firmware setup and
configuration utilities. The actual meaning of the default (compatible to
BRS-I) configuration would be highly specific to the vendor. In this example,
it could capping all harts at the same performance level, or it could mean
disabling efficiency harts.
Requirements for heterogeneous performance harts (e.g. mix of "performance"
and "efficiency" harts) are described in the "RISC-V Server Platform
specification" cite:[RSPS]. The ACPI specification cite:[ACPI] has a
chapter on "Collaborative Processor Performance Control".
Loading