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.

[pussuw]

We cannot have APIs with riscv_ prefix in public arch.h, do we need these APIs ?

[no1wudi]

How about change prefix to arch_?

[xiaoxiang781216]

public arch api should start with up_

[no1wudi]

OK

[xiaoxiang781216]

but we only need move riscv_percpu_s to public heder files, all other definition can still keep in riscv_percpu.h

[pussuw]

For example the stack pointers are needed immediately when entering exception_common. You cannot replace this functionality with anything else. I'm sorry, you need to think of something else.

[no1wudi]

How about add a new option to control this behavior?

Allow the user to choose between using percpu registers to store the TCB to accelerate scheduling or maintaining the current functionality.

[pussuw]

I guess I don't have any objections to this. It can work in flat mode.

Btw you could use tp in protected / kernel mode (CONFIG_SYSCALL=y), just swap the user tp with CSR_SCRATCH->tcb in exception_common, and update tp when a context switch occurs. This way even the protected builds could enjoy the speed benefit?

[xiaoxiang781216]

why not always enable the acceleration to simplify the code base, I don't see other arch provide this type of flexibility.

[no1wudi]

OK, let's implement it for flat build first