risc-v: Accelerate schedule by percpu

[no1wudi]

Summary

Fetch TCB info in percpu scratch register for better performance.

Similar to 948ac9b

Impact

RISC-V arch level code

Testing

ostest

[nuttxpr]

[Experimental Bot, please feedback here]

No, this PR does not fully meet the NuttX requirements. While it provides a summary of the change and mentions testing, it lacks crucial details.

Here's what's missing:

• Summary: While the what is described, the why and how are missing. Why is fetching TCB info in percpu scratch registers better for performance? Explain the mechanism and the expected performance gains. Mention any related NuttX issues.
• Impact: The impact section is overly simplistic. While it mentions RISC-V arch code, it doesn't explicitly answer the required questions. Each impact question (user, build, hardware, documentation, security, compatibility) needs a YES/NO answer followed by a description if YES. Even if the answer is NO, stating it explicitly is important for clarity. For example:
  • Impact on user: NO
  • Impact on build: NO
  • Impact on hardware: YES (Affects RISC-V architectures. No changes to existing boards or drivers, but modifies low-level architecture code.)
  • Impact on documentation: NO (or YES if documentation needs updating)
  • Impact on security: NO (or YES with explanation if applicable)
  • Impact on compatibility: NO (or YES with explanation if applicable)
• Testing: "ostest" is insufficient. Provide details about the build host (OS, CPU, compiler) and the specific RISC-V target (simulator, board, configuration) used for testing. Crucially, the testing logs before and after the change are missing. These logs are essential to demonstrate the actual performance improvement and validate the change's effectiveness. If ostest was run before and after, include the relevant output. Even a simple timing comparison would be helpful.

The PR needs to be significantly more detailed to be considered complete. Provide the missing information to ensure reviewers can properly assess the change.

[xiaoxiang781216]

why not always enable CONFIG_RISCV_PERCPU_SCRATCH

[no1wudi]

Sure, SCRATCH register is always available, I'll try to remove this option and refine relative logic first

[xiaoxiang781216]

@no1wudi let's continue on this work?

[no1wudi]

@no1wudi let's continue on this work?

Yes, I am currently doing further code cleanup and will continue with the related work once it's completed.

[no1wudi]

Use tp register should be better, let's track it by a new PR