feat(perf): features for evaluation#678
Conversation
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
…ta with features Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
the logic for passing periodic information has been internalized and solve bootloader error changing const numbers by using Box Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
| } | ||
| } | ||
|
|
||
| fn update_time_and_state_for_dag(next_state: PerfState) { |
There was a problem hiding this comment.
update_time_and_state_for_dag is an exact duplicate of update_time_and_state — not a single line differs. Despite the name implying DAG-specific behavior, both paths in start_interrupt and start_context_switch (branched via dag_info.is_some()) ultimately reach the same logic.
Please remove update_time_and_state_for_dag and consolidate both paths to call update_time_and_state directly.
There was a problem hiding this comment.
If we remove update_time_and_state_for_dag and merge it into update_time_and_state, do we no longer need to worry about the possibility that the code in start_interrupt, start_context_switch, and start_context_switch_main might be perceived as containing redundant if-else branches?
Or is the intent of this comment to eliminate all if-else branches and simply change the code to call update_time_and_state?
There was a problem hiding this comment.
For now, I’ve removed the if-else handling and made it so that update_time_and_state is called regardless of which task is received. Please let me know if this change was unintended.
There was a problem hiding this comment.
Yes, that's exactly what was intended. Since update_time_and_state_for_dag and update_time_and_state were identical, the if-else branches in start_interrupt, start_context_switch, and start_context_switch_main had no practical effect. Removing the branches and calling update_time_and_state directly is the correct fix. Thank you for making the change.
If you have a specific reason for wanting to keep update_time_and_state_for_dag, please let me know. In that case, please revert the change.
There was a problem hiding this comment.
I see. If calling the same function—whether in a regular task or a DAG task—doesn’t affect previous evaluation results, then I’m in favor of this change as well.
| const MAX_NODES: usize = 20; | ||
| #[derive(Clone)] | ||
| struct PubSubTable { | ||
| timestamps: [[[u64; MAX_NODES]; MAX_PUBSUB]; MAX_LOGS], |
There was a problem hiding this comment.
Please add comments explaining the rationale behind MAX_LOGS, MAX_PUBSUB, and MAX_NODES, and whether there is any room for tuning them. As it stands, these constants result in a static allocation of roughly 3.75 MB (8192 × 3 × 20 × 8 bytes), which is fairly large and warrants some justification.
There was a problem hiding this comment.
MAX_LOGS and MAX_NODES are adjustable constants, and I have left a comment to that effect. (Since MAX_LOGS is usually fine even if it is a bit smaller, I changed the default to 2048. The value of 2048 was chosen based on this branch.)
There was a problem hiding this comment.
The value of MAX_NODES was changed to 5.
This is because the test_dag test application, which runs the DAG, has 5 nodes. (If the user has configured a DAG with 10 nodes, this value can be changed to 10, or if the maximum number of nodes is updated frequently, it can be raised to a value that poses no issues.)
There was a problem hiding this comment.
Please add a comment explaining the rationale behind MAX_LOGS = 2048 and clarifying that this is a ring buffer.
There was a problem hiding this comment.
I added a comment.
| @@ -92,12 +93,14 @@ x86 = [ | |||
| "awkernel_drivers/uart_16550", | |||
| ] | |||
| rv32 = [ | |||
| "perf", | |||
| "no_std_unwinding", | |||
| "awkernel_lib/rv32", | |||
| "dep:ns16550a", | |||
| "awkernel_drivers/rv32", | |||
| ] | |||
| rv64 = [ | |||
| "perf", | |||
| "no_std_unwinding", | |||
| "awkernel_lib/rv64", | |||
| "dep:ns16550a", | |||
There was a problem hiding this comment.
Please address the following:
① Update the PR description — State explicitly that perf was added as a temporary workaround because tests do not pass on rv32/rv64 without it, and that the root cause has not yet been investigated. Leaving the intent undocumented will confuse anyone who looks at this later.
② Add a TODO comment
rv32 = [
# TODO: Remove once a way to pass tests without `perf` is found
"perf",
...
]③ Open a separate issue — It is recommended to track the investigation of why tests fail without perf on RISC-V in a dedicated issue. Left as-is, RISC-V builds will permanently carry the perf feature, which is likely unintended.
…ture Co-authored-by: Copilot <copilot@github.com>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
…ontext_switch etc.. Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
| let recorder = | ||
| recorder_opt.get_or_insert_with(|| Box::new(core::array::from_fn(|_| BTreeMap::new()))); | ||
|
|
||
| if recorder[log_index].get(&dag_id).copied().unwrap_or(0) == 0 { |
There was a problem hiding this comment.
Timestamp 0 is used as a sentinel value meaning "not recorded", but this cannot be distinguished from a valid value if the system uptime happens to be near 0 ns at startup (unlikely in practice, but theoretically possible). Please either consider an alternative approach or add a comment acknowledging this limitation.
| let item = $idx.recv().await; | ||
| match period_index { | ||
| Some(expected) => { | ||
| if expected != item.period_index { |
There was a problem hiding this comment.
The mismatch handling here (adopt first, warn for rest) looks fine, but could we add a comment explaining the intent?
There was a problem hiding this comment.
I added a comment.
|
|
||
| loop { | ||
| #[cfg(feature = "period-index-propagation")] | ||
| if last_print.elapsed().as_secs() >= 30 { |
There was a problem hiding this comment.
This is a magic number. Please either introduce a named constant such as const PERF_PRINT_INTERVAL_SECS: u64 = 30; or make it configurable.
| const MAX_NODES: usize = 20; | ||
| #[derive(Clone)] | ||
| struct PubSubTable { | ||
| timestamps: [[[u64; MAX_NODES]; MAX_PUBSUB]; MAX_LOGS], |
There was a problem hiding this comment.
Please add a comment explaining the rationale behind MAX_LOGS = 2048 and clarifying that this is a ring buffer.
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Signed-off-by: nokosaaan <nishimura.r.019@ms.saitama-u.ac.jp>
Description
Since period information is required during evaluation, I have provided a feature to enable evaluation outside of the application.
period-index-propagationis normally turned off, which is consistent with the behavior of the traditionalawkernel. To enable it, simply addperiod-index-propagationto thedefaultin the[features]section ofkernel/Cargo.toml.I have added
perfas a feature forrv32andrv64, but this is a temporary measure to pass tests on GitHub and is not intended to permanently addperffunctionality to these targets.The root cause of this issue has not yet been resolved and will be tracked in a separate issue.
I have updated
pubsub.rsto allow cycle propagation without altering existing trait boundaries, APIs, or the test application. Please refer to the file attached to the PR test section for the execution results.Related links
sample code
How was this PR tested?
no_feature_compile.log
no_feature_execute.log
feature_compile.log
feature_execute.log
Notes for reviewers